Update patch set 1

Patch Set 1:

(1 comment)

Patch-set: 1

7888aecf10cf6a2d0f76d0f8532e6b49114ad4ff

@@ -214,6 +214,30 @@
       "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
       "unresolved": false
     },
+    {
+      "key": {
+        "uuid": "5f7c97a3_783499ac",
+        "filename": "specs/rocky/vitrage-resources.rst",
+        "patchSetId": 1
+      },
+      "lineNbr": 84,
+      "author": {
+        "id": 12404
+      },
+      "writtenOn": "2018-07-06T05:52:25Z",
+      "side": 1,
+      "message": "\u003e I\u0027ve already written part of the\n \u003e code, it is still WIP, but will it help if I push it to gerrit, so\n \u003e you could see what I\u0027m trying to do?\n \u003e \n\nFeel free to push it up, maybe mark the title with [WIP] or -1 on the workflow will be great\n\n\n \u003e As for your questions:\n \u003e \n \u003e 1. For option 1, we need only the instance_id and not the stack_id.\n \u003e But it means that you will need to duplicate the VitrageTemplate\n \u003e block for every instance you want to have self-healing for, instead\n \u003e of writing it once for the entire stack. Alternatively, we could\n \u003e write a list of instances as an input. In option 2, the same\n \u003e healing process will work for every instance in the stack. What do\n \u003e you think?\n\nIf it\u0027s not a huge burden, I do prefer we go with option 1. that way, ops get more flex on the range of instances. Also we get to define this vitrage template resource within that Stack template\n\nAnd we can also create a auto-scaling group on top of a auto-healing template (vitrage+instance+mistral) like what you see in heat-template\n\n\n \u003e \n \u003e So for Rocky I thought of supporting only one use case using a semi\n \u003e hard-coded Vitrage template. The goal is to \"tie everything\n \u003e together\", and then as a phase 2 we can support different Vitrage\n \u003e templates.\n\nSo maybe we can add one more property call `template_type` and currently only allow `self-healing-instance`(or some better name ;) )? So once we add more kind of support, It won\u0027t conflict or backport imcompatabile.\n\n\n \u003e It might also be a good idea to\n \u003e define a property for \u0027execute_workflow\u0027 that holds the workflow_id\n \u003e and workflow_input inside.\n\nThat\u0027s good idea:)",
+      "parentUuid": "5f7c97a3_0f50bd5d",
+      "range": {
+        "startLine": 84,
+        "startChar": 10,
+        "endLine": 84,
+        "endChar": 46
+      },
+      "revId": "7888aecf10cf6a2d0f76d0f8532e6b49114ad4ff",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
+      "unresolved": false
+    },
     {
       "key": {
         "uuid": "5f7c97a3_0e84685c",