I was hoping I could get some reviewers on my pull request for Nova dynamic inventory plugin? Monty Taylor added yet more useful functionality on top of my original working. I was focused on getting it to work with more modern Novas, he added all sorts of great features such as multi-cloud, made it a class as well as cache (see pull request for full details).
Thanks for passing it by, testing would be great, as I don’t want to replace a rewrite unless some folks have helped test.
Perhaps a simple playbook run that calls nothing more than the ping module would make for a good test by other folks.
I’m not too interested in Rackspace support for multi-cloud as right now Rackspace wants to use the Rackspace inventory script for various current and future optimizations (Matt, correct me if I’m putting words in your mouth), but I can totally see HP-specifics/generic-openstack/other being nice here.
You aren’t putting words in my mouth. Ideally the way Rackspace likes to approach these things is that it should be as simple as can be for users to use our SDKs and such, by taking away the burden of having to configure too many things. With a username and API key you are ready to roll without additional knowledge of the API.
As discussed recently, the rax.py inventory script along with most of the rax modules also work with other OpenStack installs as well, we just don’t really advertise it very much, other than you can see some of the options in the modules that would enable you to do so.
This multi-cloud functionality in the rax inventory and modules was largely added to support people using both Rackspace Public and Private cloud, as well as allowing us to use the same modules to manage our cloud infra.
HP doesn’t have any specifics outside of stock OpenStack and as far as I recall (I can be corrected) that Rackspace is moving to stock openstack as well (?) and that’s one of the reasons why Monty wanted to make sure to add multi-cloud support.
My concern with Rackspace support in the nova module has nothing to do with making Rackspace happy - it has to do with making OpenStack users who happen to also be Rackspace customers happy. For instance, I currently runs a large production system that spans Rackspace Public, HP Public and two private clouds, so we tend to very explicitly use OpenStack interfaces and not vendor-specific ones, since vendor specific interfaces increase the amount of work we have to do. If the rax modules are sufficient for someone who is only a Rackspace customer, that’s awesome, truly. But I want to make very certain that the OpenStack modules work for everyone regardless of cloud vendor.
So for me, my testing involved making sure it worked with all of the running OpenStack clouds, including Rackspace, that I have accounts on and that I currently use custom written python-novaclient scripts to interact with. In a perfect world, I will be able to replace my custom written scripts with Ansible playbooks that use the nova_compute module to provision nodes and the nova_inventory plugin to manage the inventory. The posted pull request works well for me at least - a gist with the output can be found here:
(That’s just the output of our production rackspace account, I have also tested that it works in the multi-cloud config and can re-do that and re-gist it for folks if you like)
So in any case - I’ve tested the nova_inventory plugin against all of those clouds listed above. I have not tested that it works as an upgrade to my existing production setup, since I didn’t have one of those before since it did not work for me. I’d really love some help testing that the changes here don’t break previous nova_inventory users who may have had a use case we didn’t think of. But I think, from looking at the old config reading code, that it should work as expected … just perhaps with some more data returned in host_vars.
Hello,
I did another rework of the Nova inventory, I hope I am not spamming this. I tried to cover the features in your PR and add some. To compare the config, in my PR you can do sth like: