[openstack-dev] [TripleO] config-download/ansible next steps

Sergii Golovatiuk sgolovat at redhat.com
Wed Jun 13 13:32:39 UTC 2018


Hi,

On Wed, Jun 13, 2018 at 3:17 PM, James Slagle <james.slagle at gmail.com> wrote:
> On Wed, Jun 13, 2018 at 6:49 AM, Dmitry Tantsur <dtantsur at redhat.com> wrote:
>> Slightly hijacking the thread to provide a status update on one of the items
>> :)
>
> Thanks for jumping in.
>
>
>> The immediate plan right now is to wait for metalsmith 0.4.0 to hit the
>> repositories, then start experimenting. I need to find a way to
>> 1. make creating nova instances no-op
>> 2. collect the required information from the created stack (I need networks,
>> ports, hostnames, initial SSH keys, capabilities, images)
>> 3. update the config-download code to optionally include the role [2]
>> I'm not entirely sure where to start, so any hints are welcome.
>
> Here are a couple of possibilities.
>
> We could reuse the OS::TripleO::{{role.name}}Server mappings that we
> already have in place for pre-provisioned nodes (deployed-server).
> This could be mapped to a template that exposes some Ansible tasks as
> outputs that drives metalsmith to do the deployment. When
> config-download runs, it would execute these ansible tasks to
> provision the nodes with Ironic. This has the advantage of maintaining
> compatibility with our existing Heat parameter interfaces. It removes
> Nova from the deployment so that from the undercloud perspective you'd
> roughly have:
>
> Mistral -> Heat -> config-download -> Ironic (driven via ansible/metalsmith)
>
> A further (or completely different) iteration might look like:
>
> Step 1: Mistral -> Ironic (driven via ansible/metalsmith)
> Step 2: Heat -> config-download

I really like this approach. It decouples provisioning level from
deployment. As a result we may use better level of parallelism. For
instance, when we have 3 provisioned servers that match controller
roles we may start controller deployment without waiting other nodes
provisioning. For Compute role the strategy may be different such as
deploy Compute server when at least one node provisioned.

>
> Step 2 would use the pre-provisioned node (deployed-server)  feature
> already existing in TripleO and treat the just provisioned by Ironic
> nodes, as pre-provisioned from the Heat stack perspective. Step 1 and
> Step 2 would also probably be driven by a higher level Mistral
> workflow. This has the advantage of minimal impact to
> tripleo-heat-templates, and also removes Heat from the baremetal
> provisioning step. However, we'd likely need some python compatibility
> libraries that could translate Heat parameter values such as
> HostnameMap to ansible vars for some basic backwards compatibility.
>
>>
>> [1] https://github.com/openstack/metalsmith
>> [2] https://metalsmith.readthedocs.io/en/latest/user/ansible.html
>>
>>>
>>> Obviously we have things to consider here such as backwards compatibility
>>> and
>>> upgrades, but overall, I think this would be a great simplification to our
>>> overall deployment workflow.
>>>
>>
>> Yeah, this is tricky. Can we make Heat "forget" about Nova instances? Maybe
>> by re-defining them to OS::Heat::None?
>
> Not exactly, as Heat would delete the previous versions of the
> resources. We'd need some special migrations, or could support the
> existing method forever for upgrades, and only deprecate it for new
> deployments.
>
> I'd like to help with this work. I'll start by taking a look at what
> you've got so far. Feel free to reach out if you'd like some
> additional dev assistance or testing.
>
> --
> -- James Slagle
> --
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Best Regards,
Sergii Golovatiuk



More information about the OpenStack-dev mailing list