Open Stack

On Sat, Mar 14, 2020 at 8:06 AM Rabi Mishra <ramishra at redhat.com> wrote:
>
> On Sat, Mar 14, 2020 at 2:10 AM John Fulton <johfulto at redhat.com> wrote:
>>
>> 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?
>
>
> Yeah, as John mentioned, tripleo.derive_params.v1.derive_parameters workflow is surely being used for NFV (DPDK/SR-IOV) and HCI use cases and  can't be deprecated or dropped. Though we've a generic interface in tripleoclient to run any workflow in plan-environment, I have not seen it being used for anything other than the mentioned workflow.
>
> In the scope of 'mistral-ansible' work, we seem to  have two options.
>
> 1. Convert the workflow to ansible playbook 'as-is' i.e calculate and merge the derived parameters in plan-environment and as you've mentioned, change tripleoclient code to call any playbook in plan-environment.yaml and the parameters/vars.

Nice idea. I hadn't thought of that.

If there's a "hello world" example of this (which results in a THT
param in the deployment plan being set to "hello world"), then I could
try writing an ansible module to derive the HCI parameters and set
them in place of the "hello world".

  John

> 2. Move the functionality further down the component chain in TripleO to have the required ansible host/group_vars set for them to be used by config-download playbooks/ansible/puppet.
>
> I guess option 1 would be easier within the timelines. I've done some preliminary work to move some of the functionality in relevant mistral actions to utils modules[1], so that they can be called from ansible modules without depending on mistral/mistral-lib and use those in a playbook that kinda replicate the tasks in the mistral workflow.
>
> Having said that, it would be good to know what the DFG:NFV folks think, as they are the original authors/maintainers of that workflow.
>
> <snip>
>
>> 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.
>
>
> I'm not sure that would be in the scope of 'mstral-to-ansible' work. Dropping swift would probably be a bit more complex, as we use it to store templates, plan-environment, plan backups (possibly missing few more) etc  and would require significant design rework (may be possible when we get rid of heat in undercloud). In spite of heat using the templates from swift and merging environments on the client side, we've had already bumped heat's REST API json body size limit (max_json_body_size) on the undercloud to 4MB[2] from the default 1MB and sending all required templates as part of API request would not be a good idea from undercloud scalability pov.
>
> [1] https://review.opendev.org/#/c/709546/
> [2] https://github.com/openstack/tripleo-heat-templates/blob/master/environments/undercloud.yaml#L109
>
> --
> Regards,
> Rabi Mishra
>