tripleo-specs/1c13b866955721f7542d43c6cfb...

180 lines
9.0 KiB
Plaintext

{
"comments": [
{
"key": {
"uuid": "d800eea8_1205c703",
"filename": "specs/xena/directord-orchestration.rst",
"patchSetId": 3
},
"lineNbr": 36,
"author": {
"id": 7144
},
"writtenOn": "2021-08-05T19:36:04Z",
"side": 1,
"message": "It does seem that there is some overlap between Heat and Task-core. Heat is also a declarative dependency graph. However, our service template framework interface does not lend itself to being expressed that way (no way to express dependencies between services, or ordering, etc). Instead we have rigid task lists.\n\nAs an alternative, we could look at how we would express this all using Heat templates. This:\nhttps://github.com/mwhahaha/task-core/blob/main/examples/directord/services/openstack-keystone.yaml\nis actually not all that different from the existing keystone service template from tripleo-heat-templates. We could evolve the t-h-t service framework interface into what we need as well, instead of building out all these task-core services.\n\nI\u0027d like to see a psuedo-code example of how this would all flow end to end. The line between Heat and task-core is not well understood. It feels like we\u0027re handing off from one dependency graph to another.\n\nIf we boil down what task-core does as \"figuring out the right order of all the directord executions\"...then couldn\u0027t Heat do that as well if we had a service template framework that expressed dependencies, and let Heat solve for those instead of passing it off to task-core?\n\nIt feels as if task-core is the answer to heat-as-a-library. I see a lot of overlap between the 2 tools intended functionality. Not necessarily in how we use them, because we don\u0027t fully take advantage of Heat\u0027s ability to order things and solve dependencies, instead we implemented rigid steps and ordering.",
"revId": "1c13b866955721f7542d43c6cfb514d80632b2ae",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": true
},
{
"key": {
"uuid": "104c2b1c_78f6428d",
"filename": "specs/xena/directord-orchestration.rst",
"patchSetId": 3
},
"lineNbr": 36,
"author": {
"id": 7353
},
"writtenOn": "2021-08-06T15:15:14Z",
"side": 1,
"message": "I would like to refrain from putting pseudo code in this spec as I feel it is more distracting than helpful. That said, we have put together examples of how this would all tie together within THT, one of which can be seen here: https://review.opendev.org/c/openstack/tripleo-heat-templates/+/798747\n\nThere may be a lot of overlap between Heat and Task-Core, which I think is helpful to highlight. With Task-Core, we\u0027re able to implement most, if not all, of what we need in a tiny utility with minimal dependencies that should™ be far easier to maintain long term. That being said, there\u0027s no design on replacing heat wholesale, heat templates are our user interface. However, we can marginalize Heat substantially, and potentially excise it in a future iteration should we ever find the need or desire.",
"parentUuid": "d800eea8_1205c703",
"revId": "1c13b866955721f7542d43c6cfb514d80632b2ae",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": true
},
{
"key": {
"uuid": "aa1a6184_c8031e70",
"filename": "specs/xena/directord-orchestration.rst",
"patchSetId": 3
},
"lineNbr": 134,
"author": {
"id": 7144
},
"writtenOn": "2021-08-05T19:36:04Z",
"side": 1,
"message": "Can we see an example of this? Even if it\u0027s pseudo-code.\nI think it will help close the gaps on the big picture of the end to end flow.",
"revId": "1c13b866955721f7542d43c6cfb514d80632b2ae",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": true
},
{
"key": {
"uuid": "e92ff57b_2bb82e82",
"filename": "specs/xena/directord-orchestration.rst",
"patchSetId": 3
},
"lineNbr": 134,
"author": {
"id": 7353
},
"writtenOn": "2021-08-05T20:06:59Z",
"side": 1,
"message": "We have examples, but none here in the spec. I left specific code examples out of the spec because each repository has it\u0027s own examples and documentation: https://github.com/mwhahaha/task-core/blob/main/examples/directord/services/openstack-keystone.yaml",
"parentUuid": "aa1a6184_c8031e70",
"revId": "1c13b866955721f7542d43c6cfb514d80632b2ae",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": true
},
{
"key": {
"uuid": "35f2c59f_ab9694cf",
"filename": "specs/xena/directord-orchestration.rst",
"patchSetId": 3
},
"lineNbr": 134,
"author": {
"id": 7144
},
"writtenOn": "2021-08-05T21:04:51Z",
"side": 1,
"message": "By \"refactored\" then, do you mean t-h-t service templates will be replaced by that openstack-keystone.yaml example from task-core?\n\nI didn\u0027t think that was the case, as it breaks the user interface for how we presently configure Keystone.\n\nThe example I\u0027m looking for would illustrate the link between tripleo-heat-templates/deployment/keystone/keystone-container-puppet.yaml and task-core/examples/directord/services/openstack-keystone.yaml.\n\nDoes one generate the other? Influence the other in some way? Or is the task-core one a full pluggable replacement and we would no longer use the template from t-h-t for keystone? Given that they both are a complete overlap of functionality (install, bootstrap, configure, launch keystone), how are they related, or is it one or the other?\n\nI\u0027m trying to understand what the end picture looks like and how the heat templates are still used (if at all) once this spec is implemented.",
"parentUuid": "e92ff57b_2bb82e82",
"revId": "1c13b866955721f7542d43c6cfb514d80632b2ae",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": true
},
{
"key": {
"uuid": "fd55b842_430b133a",
"filename": "specs/xena/directord-orchestration.rst",
"patchSetId": 3
},
"lineNbr": 134,
"author": {
"id": 7353
},
"writtenOn": "2021-08-06T15:15:14Z",
"side": 1,
"message": "Refactoring will be within the in heat-template Ansible tasks. The heat templates themselves will remain mostly intact, keeping the user interface the same. The heat template would be responsible for the generation of input into task-core which would then invoke either Ansible or Directord to execute a deployment.",
"parentUuid": "35f2c59f_ab9694cf",
"revId": "1c13b866955721f7542d43c6cfb514d80632b2ae",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": true
},
{
"key": {
"uuid": "c6690ee1_52cdcc10",
"filename": "specs/xena/directord-orchestration.rst",
"patchSetId": 3
},
"lineNbr": 409,
"author": {
"id": 7144
},
"writtenOn": "2021-08-05T19:36:04Z",
"side": 1,
"message": "Heat would be between the TripleOClient and Task-Core boxes, correct? Can we add it to the diagram so that it\u0027s more clear that Heat is still part of the picture, and also articulate what it\u0027s still doing?\n\nI think it would help to clear up a lot of the questions around what exactly is targetted at being replaced by directord + task-core (it\u0027s Ansible, not Heat).",
"revId": "1c13b866955721f7542d43c6cfb514d80632b2ae",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": true
},
{
"key": {
"uuid": "9ccf556d_e3567f79",
"filename": "specs/xena/directord-orchestration.rst",
"patchSetId": 3
},
"lineNbr": 409,
"author": {
"id": 7353
},
"writtenOn": "2021-08-05T20:06:59Z",
"side": 1,
"message": "Ack",
"parentUuid": "c6690ee1_52cdcc10",
"revId": "1c13b866955721f7542d43c6cfb514d80632b2ae",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
},
{
"key": {
"uuid": "b3a1a7c5_22eb5b67",
"filename": "specs/xena/directord-orchestration.rst",
"patchSetId": 3
},
"lineNbr": 439,
"author": {
"id": 7144
},
"writtenOn": "2021-08-05T19:36:04Z",
"side": 1,
"message": "slagle",
"revId": "1c13b866955721f7542d43c6cfb514d80632b2ae",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": true
},
{
"key": {
"uuid": "696eee7f_61376019",
"filename": "specs/xena/directord-orchestration.rst",
"patchSetId": 3
},
"lineNbr": 439,
"author": {
"id": 7353
},
"writtenOn": "2021-08-05T20:06:59Z",
"side": 1,
"message": "Ack",
"parentUuid": "b3a1a7c5_22eb5b67",
"revId": "1c13b866955721f7542d43c6cfb514d80632b2ae",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
"unresolved": false
}
]
}