On Fri, Mar 13, 2020 at 3:27 PM Kevin Carter <kecarter@redhat.com> wrote:
Hello stackers,
In the pursuit to remove Mistral from the TripleO undercloud, we've discovered an old capability that we need to figure out how best to handle. Currently, we provide the ability for an end-user (operator / deployer) to pass in "N" Mistral workflows as part of a given deployment plan which is processed by python-tripleoclient at runtime [0][1]. From what we have documented, and what we can find within the code-base, we're not using this feature by default. That said, we do not remove something if it is valuable in the field without an adequate replacement. The ability to run arbitrary Mistral workflows at deployment time was first created in 2017 [2] and while present all this time, its documented [3] and intra-code-base uses are still limited to samples [4]. As it stands now, we're on track to making Mistral inert this cycle and if our progress holds over the next couple of weeks the capability to run arbitrary Mistral workflows will be the only thing left within our codebase that relies on Mistral running on the Undercloud.
So the question is what do we do with functionality. Do we remove this ability out right, do we convert the example workflow [5] into a stand-alone Ansible playbook and change the workflow runner to an arbitrary playbook runner, or do we simply leave everything as-is and deprecate it to be removed within the next two releases? Although it would be perfectly acceptable to keep Mistral around a little while longer, it would also be a bummer if this one capability was the only reason we were not able to remove Mistral from the Undercloud.
Any and all feedback from operators, deployers, developers, former developers, etc would be greatly appreciated.
Thank you in advance.
Hey Kevin, +Saravanan +Jaganathan +Alan and I collaborated on the derive parameters feature. We used Mistral because that was the recommended method at the time. I think the same functionality could be implemented in Ansible. Derive parameters is used for both HCI and NFV deployments which benefit from specific tuning relative to the hardware used. Though a deployer can determine the appropriate tuning and put those values in their environment files to override the defaults, determining them can be error prone or tedious. The feature uses information from introspection and some formulas recommended by performance engineers to determine the value automatically and then dynamically populate the tuned values in the environment file. The Mistral based workflow took advantage of the deployment plan which was stored in Swift on the undercloud. My understanding is that too is going away. At the moment there's a number of parameter transformations which happen along this path: mistral --> deployment plan --> heat --> ansible The Heat to Ansible layer is one place to move the translation. E.g. we could have a Heat parameter to trigger the feature and then have new ansible roles which compute the desired values during the execution of config-download. They'd need to have access to the introspection data as a prerequisite. I'm not sure this email exchange will be sufficient though to redesign the feature. I'm curious what Saravanan thinks. Do we need a blueprint or spec to change it and do the work during Victoria? John
[0] https://opendev.org/openstack/python-tripleoclient/src/commit/af719b795bc9ba... [1] https://opendev.org/openstack/python-tripleoclient/src/commit/af719b795bc9ba... [2] https://review.opendev.org/#/c/457874 [3] https://specs.openstack.org/openstack/tripleo-specs/specs/pike/tripleo-deriv... [4] https://opendev.org/openstack/tripleo-heat-templates/src/commit/48da6a139367... [5] https://opendev.org/openstack/tripleo-common/src/commit/cc4f9c57b708259e9e94...
Kevin Carter IRC: kecarter