Update patch set 5

Patch Set 5:

(1 comment)

Patch-set: 5
Reviewer: Gerrit User 14985 <14985@4a232e18-c5a9-48ee-94c0-e04e7cca6543>

975c7280c649e390625700604c793d41bf05e32c

@@ -582,6 +582,30 @@
       "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
       "unresolved": true
     },
+    {
+      "key": {
+        "uuid": "949f2358_644f2d3e",
+        "filename": "specs/xena/directord-orchestration.rst",
+        "patchSetId": 4
+      },
+      "lineNbr": 421,
+      "author": {
+        "id": 14985
+      },
+      "writtenOn": "2021-08-11T13:35:16Z",
+      "side": 1,
+      "message": "\u003e This is what I\u0027d like to see an example of if that\u0027s the plan. Especially if we expect service owners to eventually do this work. If they\u0027re going to have to be invested enough to do the work, I think we need to show it at least in a pseudo-code manner.\n\nHonestly we\u0027ve done more with less in spec form.  I appreciate this however I think the examples provided are sufficient because they are the tasks that would effectively be included into the existing THT services.  \n\n\u003e Yes, but only because of how we\u0027ve written the service templates. Heat is actually great at ordering. It\u0027s a declarative dependency graph, same as taskflow. Even though we\u0027ve separated the execution from the ordering, we could still use Heat to figure out dependencies and ordering, generate the imperative sequential execution steps, and then pass it off to something like directord to execute. Granted, it would be a significant refactoring in our internal template architecture in how things are laid out. Our usage of ServiceChain/ResourceChain ends up being opaque to Heat, and it has no way to order dependencies between services. That would need to change. I\u0027m not specifically proposing that, Although I would be interested in Rabi\u0027s thoughs around this approach.\n\n\nThe goal here is to maintain backwards compatibility so that maybe we could actually backport and leverage this for upgrades.  We could leverage both but the issue really comes around run time dynamic execution order which heat won\u0027t solve. We could leverage the service chain for some elements of execution to restrict the scope of the execution ordering but today we already have this concept in ansible.  We\u0027re honestly not proposing anything new here but rather simplifying and explicitly using smaller code bases to handle the function. Right now this functionality is spread across heat/ansible.  The goal would be to have heat process templates and handle dynamic configuration information. Task-core figures out ordering based on what is inputted. Directord does the execution.  \n\n\n\u003e I would agree with James and I think we should carefully examine the option with using Heat as a dependency graph builder (without actual execution). Adding more components (task-core and taskflow) into tripleo violates the simplification trend.\n\nAs just mentioned this is already a thing today in ansible. It\u0027s simplification because the code to handle the functionality is scoped to a specific project and doesn\u0027t include tons of code that we don\u0027t actually leverage (e.g. ansible).",
+      "parentUuid": "c8af848d_d71246e8",
+      "range": {
+        "startLine": 421,
+        "startChar": 24,
+        "endLine": 421,
+        "endChar": 71
+      },
+      "revId": "975c7280c649e390625700604c793d41bf05e32c",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
+      "unresolved": true
+    },
     {
       "key": {
         "uuid": "975093cb_cbd9f7bf",