If you could not attend the last OpenStack Summit in Atlanta and you are interested by Puppet, this article is for you.
First feedback: I was so happy to see dedicated sessions for Automation and OPS subjects. We got plenty of sessions where we could share experiences about the reality of OpenStack in production. Most people present in these sessions were OpenStack users. Some of them had interesting use-cases when deploying OpenStack at scale using Automation tools.
Tuesday afternoon
Puppet Design Session
Puppet seems like the most-used automation software to install OpenStack in production today. With other Puppet OpenStack core-developers, contributors and users, we talked about some schedule for Juno release.
First of all, we need to work on new modules that will be hosted on Stackforge and obviously released by Puppet Forge: puppet-trove and puppet-marconi.
I have already started writing the puppet-trove module and made it available on the eNovance github page, but it’s still in early stage to use it. Once I’ll get something working and tested, I’ll move it to Stackforge.
Nobody took the responsibility to work on puppet-marconi module. If you are interested, please rise a thread on the Puppet OpenStack mailing-list to coordinate with folks.
Regarding puppet-neutron, we are doing a refactorization of the OVS agent configuration. This is a work in progress: https://review.openstack.org/#/c/82353 but it should be finished soon, as we get some feedback from users who needed it. You will be able to properly use ML2 Plugin with OVS agent when using Neutron.
We were wondering about file/directory permissions in our modules and we think it’s up to packaging to configure it. Some work could be done to delete it from our modules. Since there is current code ensuring the permissions, we won’t break it to keep backward compatibility and warn the users.
Some folks suggested to move from CLI to API in our providers. Chris Hoge (Puppetlabs Developer in charge of OpenStack modules) will draft a blueprint and delegate work if it lacks volunteers.
By the way, regarding blueprints, we are going to follow the OpenStack way to write spec, by creating a new repository in Stackforge, where people could write blueprints and got some reviews from other developers.
Michael Chapman (Software Engineer at Aptira) is the author of the awesome openstacklib library, used to manage OpenStack resources (endpoints, databases, etc). He plans to move the code to puppet-openstack-cloud. This code will help the community to write manifests when deploying OpenStack. Note this module would also be useful to configure HAproxy & other services used to install OpenStack. We thought about deprecating puppet-openstack module, to use this new common library.
He also plans to move his MySQL Galera puppet module to Stackforge to take advantage of the QA and maybe bring more people contributing on this module.
We also got the idea to move to configuration providers in puppet-swift, with the goal to configure object storage using a clean way. That’s a lot of work and we won’t keep backward compatibility. The code will be out in Juno release.
Michael worked hard in Havana release to have a better coverage of parameters documentation. We are going to add a ‘non-voting’ Jenkins job to check if each patch contains the documentation from the OpenStack upstream code. It will help people documenting parameters using the appropriate words. The idea is to get 100% coverage in our modules! That’s a great challenge, and it will require some work… We will see how it’s going by the end of the release.
Regarding the project organization, Chris proposed a regular meeting to keep synchronization between all the work we have to do in Juno release. The date is not fixed yet, we are looking for a schedule good for everyone, which is not an easy task since major contributors are very far from each others! Everyone will be welcomed to join the conversation of course.
Mirantis proposed to improve the gate for our Puppet modules and to add functional testing in the CI Jenkins jobs. We look forward to see this work coming, which is clearly something we need.
Cisco and Aptira made an awesome work on puppet-openstack-builder, which is an OpenStack bootstrap tool using our modules in a very flexible way, as well as puppet-openstack-cloud module. eNovance is really motivated to push some efforts to contribute on this work and we will see how we can factorize more code that we have in common regarding our way to install OpenStack.
The session finished by asking to the community to improve contributions by submitting code for review and report new bugs in Launchpad. It’s good to see a lot of users, but I also love seeing new contributing joining our team. If you are interested, feel free to join us on our freenode IRC channel: #puppet-openstack.
Friday afternoon
Puppet feedback
Who is using OpenStack Puppet modules? 70% of OpenStack deployments. It’s a lot! The majority installs Havana release on Ubuntu.
We asked folks in the room who actually used upstream modules, and it seems a lot of them are using forked repositories and patch themselves the modules for their specific needs.
We think this is not the right way, because a come back to the upstream could be a weird task after a long time without rebasing. If you think review process is too long for you, you should ping developers on IRC directly. Each patch requires clean manifests, unit tests and documentation. Otherwise, it will automatically get a -1. In general, people seem happy with the review process, we have to continue in that way.
People were wondering about the upgrade to Icehouse and great news, our modules support Icehouse for all components!
We are currently deploying Icehouse with the upstream puppet modules and our high-level module: https://github.com/enovance/puppet-openstack-cloud
To process the upgrade, you will have to manage by yourself the orchestration to make it without downtime. At eNovance, to make this happen we use eDeploy and Ansible playbooks.
Last but not least, we are considering creating a new Puppet module to configure Monitoring for OpenStack services. Since most people are using different ways to make it, we will do something flexible and standard to match most common use-cases.
I think you’ve seen there is a lot of work coming in the next months. I repeat myself, but we are looking for new contributors with knowledges in Puppet & OpenStack deployments.
Feel free to join us, we are cool and we don’t bite 😉
Thank you very much ! You have cleared out the difference between them.