Open Stack

On Fri, Mar 13, 2020 at 3:27 PM Kevin Carter <kecarter at 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/af719b795bc9ba2b2c3dbcec855990ef815bfc2c/tripleoclient/workflows/parameters.py#L33-L74
> [1] https://opendev.org/openstack/python-tripleoclient/src/commit/af719b795bc9ba2b2c3dbcec855990ef815bfc2c/tripleoclient/v1/overcloud_deploy.py#L221-L224
> [2] https://review.opendev.org/#/c/457874
> [3] https://specs.openstack.org/openstack/tripleo-specs/specs/pike/tripleo-derive-parameters.html
> [4] https://opendev.org/openstack/tripleo-heat-templates/src/commit/48da6a139367f21c4dfcd4afcbce1090cfc5f329/plan-samples/plan-environment-derived-params.yaml#L9
> [5] https://opendev.org/openstack/tripleo-common/src/commit/cc4f9c57b708259e9e946c6d0c45709b3ffaabe2/workbooks/derive_params.yaml
>
>
> Kevin Carter
> IRC: kecarter