About OpenStack Puppet modules
OpenStack has a lot of projects and all need to be configured to make an infrastructure working as we want. That means we needs one puppet module by project. Like we have in most of modules, each of them is made up of several class definitions, resource declarations, defined resources, and custom types/providers.
Multiple companies and individuals contributed to this module with the goal of producing an efficient way to install ready-for-production infrastructures that was based off documented OpenStack best practices.
What’s new this summer ?
For people who was in vacation, this article could be useful since it sums up what happens this summer on OpenStack Puppet modules.
Module renaming
As you may know, Quantum (Networking as a Service in OpenStack) has been renamed in Neutron because of trademarks issues. Let me picture you the kind of patchs:
find . -type f -print0 | xargs -0 sed -i 's/quantum/neutron/g'
.. in puppet-quantum, puppet-nova and puppet-horizon.
All of them have been tested by units-tests and of course by deployments. Since everything went fine, you could now go ahead and install Neutron with the new puppet module.
Module versioning
An interesting conversation was launched a couple of weeks ago about modules versioning. All the modules have now the same conventions that we have in OpenStack Core projects:
- Master : Current development branch (today: Havana)
- stable/grizzly : Current stable branch. As we could do in OpenStack, backports / cherry-picks are possible to stable branches.
You should take care if you have running infrastructure that use current master branch, mainly for the puppet-neutron module if you are running Grizzly.
Launchpad support
To follow the OpenStack stream, we also created a dedicated launchpad project for each module. **
- puppet-nova
- puppet-keystone
- puppet-neutron
- puppet-horizon
- puppet-glance
- puppet-swift
- puppet-ceilometer
- puppet-heat
- puppet-tempest
Like you use to do it in OpenStack, you can now file a bug or submit a blueprint for each puppet module. Also, you can use the same process in gerrit to fix a bug or implement a blueprint.
A new Kid in the Neighbourhood
eNovance (the company I’m working for) decided to move the puppet-heat repository in Stackforge which is the best place to welcome new puppet modules related to OpenStack. Deploying Heat in production would never be a problem for you with this new module.
No more lint ERRORS, almost no more WARNING
A big clean-up has been done to delete all puppet-lint ERROR messages that we had on modules. Also, we are currently cleaning all the modules to fix the WARNING messages, and the work is almost done, thank’s to contributors. Please note that puppet-lint is now voting on OpenStack Gerrit process, so don’t forget to run “rake lint” before pushing your contribution ;-).
Conclusion
A lot of work has been done on Puppet modules. There is no doubt to say that puppet modules are designed for high-quality and best-practices configurations around an important community who takes care of those concepts. If you want to contribute, it’s exactly the same process like another OpenStack project:
- File a bug
- Submit a blueprint
- Make a patch with git review
More documentation here.
[…] http://blogs.rdoproject.org/5975/why-openstack-puppet-modules-did-not-have-vacation Published by Emilien Macchi on 19/08/2013 | Leave a […]