Open Stack

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

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
--