Ansible project is maturing and changing the way we deliver Ansible content to the users. And while Ansible Galaxy is already a goto place for finding roles, it is now becoming a central hub for all things Ansible. So you might wonder: how does this change affect us: the community of Ansible content producers?
Well, here is the thing. We are presenting a session called How to build Ansible Collections: Experience from community members at the AnsibleFest in Atlanta, where we will talk about the lessons we learned while developing and maintaining Ansible collections. What follows is a gentle introduction and invitation to our talk.
Update (2019-11-28): We had a great time presenting that session thanks to all of you who came and listened to us blabbing about collections while showing you mechanical octopuses in the background ;) And if you missed our presentation, we have some good news for you: you can watch a video recording of our talk on Ansible’s web page.
Collections? What collections?
We all know that Ansible is in principle an execution engine that bosses various plugins and modules around, right? Right. Currently, most of the plugins and modules that we know and love, live in the central Ansible git repository. And when we install Ansible, we also install all of the plugins and modules.
Current Ansible architecture.
The idea behind collections is simple: move the related plugins and modules into a separate repository, package them independently from Ansible, and use Ansible Galaxy to distribute them to users. While the idea is simple, the effects this idea has on our code and development process are quite profound.
Future Ansible architecture.
The bright side
The number one thing that we (the content producers) gain is the ability to deliver our Ansible plugins and modules to the users faster because Ansible’s release cycle no longer applies to us. When we find a bug in our code, we can patch it and release a new version of the collection on the Ansible Galaxy almost immediately. And let us face it: if we have at least a moderate amount of code in our repository, there are plenty of bugs waiting to show their ugly head at the most inappropriate moment.
And while we are talking about bugs: did you ever try to file an Ansible bug? There is so much code in Ansible’s git repository that maintainers rely heavily on the metadata to properly tag reported issues. As a consequence, we need to enter some exact data when filling a new bug report or risk losing the bug in the sea of other 4000 bug reports.
Losing a bug report becomes almost impossible if we have our collection hosted in a separate repository. Why? Because less code means fewer bugs. As simple as that.
Last but not least, a smaller and more streamlined core of Ansible means happier core developers. And there is nothing better than a happy developer that is trying to help you resolve a potential issue in the code.
The dark side
Of course, it is not all sunshine and roses. Because our collection lives in a separate repository now, we can no longer rely on Ansible developers to make sure our plugins and modules are kept up to date. If Ansible changes and breaks our module or plugin, we need to be able to detect this breakage and prepare a fix for it.
But how can we detect this breakage? Well, by having a proper test suite, of course! We can then continuously run this test suite against supported and development Ansible versions. At the moment, that would most likely mean continually testing against the two Ansible versions that support collections. But as Ansible matures, we can expect this number to change a bit.
Setting up a continuous integration process is not as hard as it used to be. There exists a wide variety of free and paid options that integrate neatly with most repository hosts. But writing a robust set of tests is a bit harder, especially if our code is a giant pile of spaghetti.
We will not give any specific guides on how to write high-quality Ansible plugins and modules since these are beyond the scope of this post. But there are two rules that we should never break:
- Make sure our plugins and modules are focused. They should do one thing and one thing only.
- We better have a use case for our plugin or module. Code needs to have a purpose. Otherwise, it is just a breeding ground for bugs.
If we follow those two principles, we should be just fine.
Conclusion
The future seems bright for us content producers. Changes in Ansible’s content delivery mechanisms will force us to keep our code maintainable and well tested. But then again, we might just as well start doing your job correctly ;)
Tell us what you think about the upcomming changes on Twitter or Reddit. Or visit us at our booth 311 at the AnsibleFest in Atlanta and talk to us in person.
Cheers!
