Update patch set 3

Patch Set 3: Code-Review-1

(5 comments)

2 nits and 3 regular comments. Getting better.

Patch-set: 3
Reviewer: Gerrit User 30491 <30491@4a232e18-c5a9-48ee-94c0-e04e7cca6543>
Label: Code-Review=-1

56bc6c139d786f9b2eb7ba50eee6a2525d343cfe

@@ -0,0 +1,73 @@
+{
+  "comments": [
+    {
+      "key": {
+        "uuid": "a83d448e_a03a3481",
+        "filename": "specs/xena/implemented/vm-evacuations-for-host-recovery.rst",
+        "patchSetId": 3
+      },
+      "lineNbr": 70,
+      "author": {
+        "id": 30491
+      },
+      "writtenOn": "2021-07-29T09:34:57Z",
+      "side": 1,
+      "message": "I don\u0027t see how it\u0027s helpful to have this data duplicated in this table - it\u0027s the same for all evacuations from a single notification. The notification has the host.",
+      "range": {
+        "startLine": 69,
+        "startChar": 0,
+        "endLine": 70,
+        "endChar": 20
+      },
+      "revId": "56bc6c139d786f9b2eb7ba50eee6a2525d343cfe",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
+      "unresolved": true
+    },
+    {
+      "key": {
+        "uuid": "810c725c_51d05f16",
+        "filename": "specs/xena/implemented/vm-evacuations-for-host-recovery.rst",
+        "patchSetId": 3
+      },
+      "lineNbr": 74,
+      "author": {
+        "id": 30491
+      },
+      "writtenOn": "2021-07-29T09:34:57Z",
+      "side": 1,
+      "message": "drop the \u0027d\u0027",
+      "range": {
+        "startLine": 74,
+        "startChar": 84,
+        "endLine": 74,
+        "endChar": 85
+      },
+      "revId": "56bc6c139d786f9b2eb7ba50eee6a2525d343cfe",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
+      "unresolved": true
+    },
+    {
+      "key": {
+        "uuid": "42e24506_f588f42d",
+        "filename": "specs/xena/implemented/vm-evacuations-for-host-recovery.rst",
+        "patchSetId": 3
+      },
+      "lineNbr": 75,
+      "author": {
+        "id": 30491
+      },
+      "writtenOn": "2021-07-29T09:34:57Z",
+      "side": 1,
+      "message": "ignored",
+      "range": {
+        "startLine": 75,
+        "startChar": 70,
+        "endLine": 75,
+        "endChar": 78
+      },
+      "revId": "56bc6c139d786f9b2eb7ba50eee6a2525d343cfe",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
+      "unresolved": true
+    }
+  ]
+}

7799bda702d83f28406249e2c8babc3f4cae0bfe

@@ -1042,6 +1042,24 @@
       "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
       "unresolved": true
     },
+    {
+      "key": {
+        "uuid": "5cf38657_ecd197c7",
+        "filename": "specs/xena/implemented/vm-evacuations-for-host-recovery.rst",
+        "patchSetId": 2
+      },
+      "lineNbr": 90,
+      "author": {
+        "id": 30491
+      },
+      "writtenOn": "2021-07-29T09:34:57Z",
+      "side": 1,
+      "message": "Even then, I would still opt to include migration_uuid for provenance. Since you will be collecting dest_host, it is easy to include migration_uuid already. We can improve the Nova API to include migration_uuid everywhere to have a more optimal and reliable query on the Nova API.",
+      "parentUuid": "579a3ac8_e900954c",
+      "revId": "7799bda702d83f28406249e2c8babc3f4cae0bfe",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
+      "unresolved": true
+    },
     {
       "key": {
         "uuid": "359a85fc_d632460a",
@@ -1089,6 +1107,30 @@
       "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
       "unresolved": true
     },
+    {
+      "key": {
+        "uuid": "dc1e1445_7654726b",
+        "filename": "specs/xena/implemented/vm-evacuations-for-host-recovery.rst",
+        "patchSetId": 2
+      },
+      "lineNbr": 92,
+      "author": {
+        "id": 30491
+      },
+      "writtenOn": "2021-07-29T09:34:57Z",
+      "side": 1,
+      "message": "Hmm, but this table is for evacuations. Do you want to track reverts in the very same table? I would assume we would track reverts in a separate table (they are a different beastie and will likely use live migration or at least regular migration, not evacuation). In this table we would add a reference to the created revert. I still think we shouldn\u0027t have this prefix. We are tracking the status of the evacuation. Other statuses should have their own fields. If you think we should track revert here directly, then why not have revert_status? Clobbering previous final status makes it uglier to handle scenarios like \"show how complete evacuations for this notification are\".",
+      "parentUuid": "c0f5f3c3_a41424d4",
+      "range": {
+        "startLine": 92,
+        "startChar": 55,
+        "endLine": 92,
+        "endChar": 64
+      },
+      "revId": "7799bda702d83f28406249e2c8babc3f4cae0bfe",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
+      "unresolved": true
+    },
     {
       "key": {
         "uuid": "d0363dac_3a9e3253",