Slightly hijacking the thread to provide a status update on one of the items :)

On 06/12/2018 07:04 PM, James Slagle wrote:
I wanted to provide an update on some next steps around config-download/Ansible
and TripleO. Now that we've completed transitioning to config-download by
default in Rocky, some might be wondering where we're going next.


4. Ansible driven baremetal deployment

Dmitry Tantsur has indicated he's going to be looking at driving TripleO
baremetal provisioning with Ironic and ansible directly. This would remove
Heat+Nova from the baremetal provisioning workflows we currently use.

I'm actually already looking, my efforts just have not become visible yet.

I started with reviving my old metalsmith project [1] to host the code we need to make this happen. This now has a CLI tool and a very dump (for now) ansible role [2] to drive it.

Why a new tool? First, I want it to be reusable outside of TripleO (and outside of ansible modules), thus I don't want to put the code directly into, say, tripleo-common. Second, the current OpenStack Ansible modules are not quite sufficient for the task:

1. Both the os_ironic_node module and the underlying openstacksdk library lack support for the critically important VIF attachment API. I'm working on addressing that, but it will take substantial time (e.g. we need to stabilize the microversion support in openstacksdk).

2. Missing support for building configdrive. Again, can probably be added to openstacksdk, and I'll get to it one day.

3. No bulk operations. There is no way, to my best knowledge (please tell me I'm wrong), to provision several nodes in parallel via the current ansible modules. It is probably solvable via a new ansible module, but also see the next points.

4. No scheduling. That is, there is no way out-of-box to pick a suitable node for deployment. It can be done in pure ansible in the simplest case, but our case is not the simplest. Particularly, I don't want to end up parsing capabilities in ansible :) Also one of the goals of this work is to provide better messages than "No valid hosts found".

5. On top of #3 and #4, it is not possible to operate at the deployment level, not on the node level. From the current Heat stack we're going to receive a list of overcloud instances with their roles and other parameters. Some code has to take this input and make a decision on whether to deploy/undeploy something. It's currently done by Heat+Nova together, but they're not doing a great job in some corner cases. Particularly, replacing a node may be painful.

So, while I do plan to solve #1 and #2 eventually, #3 - #5 require some place to put the logic. Putting it to TripleO or to ansible itself will preclude reusing it outside of TripleO and ansible accordingly. So, metalsmith is this place for now. I think in the far future I will try proposing a module to ansible itself that will handle #3 - #5 and will be backed by metalsmith. It will probably have a similar interface to the current PoC role [2].

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.


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?


OpenStack Development Mailing List (not for usage questions)

Reply via email to