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  to host the code we need
to make this happen. This now has a CLI tool and a very dump (for now) ansible
role  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 .
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 
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)