Open Stack

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

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

Dmitry