In Configuration Management, Community Matters – InApps 2022

Configuration management might not be as sexy as some of the other topics we cover, but it still plays a critical role in the process for deploying, maintaining and monitoring almost every complex system.

One of the major threads throughout the talks at the Config Management Camp, held in Berlin on Nov. 15 was the importance of participating in the configuration management community.

The leading configuration management platforms, like Ansible, Chef, Puppet, and others, are open source products, rather than proprietary technologies, and the collective community around these technologies is an important component of these solutions. When you ask about the best part of this community, the most common response is “the people,” since they tend to be welcoming, friendly, knowledgeable, and most importantly, helpful.

Many of the tips, suggestions, and ideas about community certainly apply to other projects beyond configuration management, but this is a segment of the stack that has embraced community participation and open source from the beginning. This community-oriented mindset shines through at configuration management and other DevOps events where even people working for competing companies can often be found discussing new ideas and ways to work together.

Config Management Camp is even organized by a group of volunteers, many of whom work for competing companies or technologies, who put aside their differences to do something that helps everyone. This isn’t to say that the community is perfect, there are some challenges. For example, many users extend the software and contribute those extensions for other people to use, but the quality tends to vary widely, and too many of these extensions are abandoned when the original author moves on to focus on other things. However, in the Puppet community, a group called Vox Pupuli has formed to help ensure that critical modules are maintained.

We tend to be big fans of automation in this space, and automation of our own developer processes can have an impact on contributions, noted Puppet technical product manager Eric Sorenson, who offered quite a few useful tips for maintainership and contribution of these open source configuration management tools.

Sorenson pointed out that automated tests triggered by pull requests can speed up contributions since you know right away if something caused a regression or a failure, which allows you to merge good changes more quickly. He also talked about how ChatOps has really taken off with integrations from monitoring, build systems, and more to see the consequences of every change right in the chat where all of the developers are already hanging out anyway. Sorenson also had some specific advice for contributors and maintainers.

For contributors:

• Look for a project that suits your temperament as well as your technical skills.
• If you’re going to embark on a big feature or refactor, spend a little time talking about it first!
• Work on pull requests iteratively and don’t be afraid to push up a bunch of commits and squash it later.
• Work with your organization to get approval to contribute back.

For maintainers:

• Set up testing infrastructure so you can give commit bits — find or create a slack community.
• Don’t tolerate jerks.
• Have design discussions in the open.
• Find some way to flag your issues as being newbie-friendly.

Providing good code reviews is another way to encourage community members to make contributions to your project, and this topic was covered nicely in IBM OpenStack engineer Spencer Krum’s presentation, “Code Review for Operations.”

YOLO Reviews

People tend to have different perspectives on code review, but Krum looks at it as “landing code only after it has been inspected for defects and accuracy by multiple team members.” There are a few ways we tend to behave that can have a sizable impact on code reviews.

One of these behaviors is what Krum refers to as “YOLO reviews.” The first review might not be great, which dumps responsibility onto the second person who approves it, and then it gets pushed to production after that second review. This puts tremendous stress on the second person. This issue works in the other direction, too. If a smart person gave the first positive review, it must be good, and the second person rubber stamps it without giving it the expected thorough consideration.

https://twitter.com/mikhailgarber/status/634855466972024832

Patch size can also have a big impact of code review quality. Smaller patches get more detailed reviews while enormous patches are sometimes pushed through or ignored when nobody has time to do a comprehensive review on an enormous patch.

He also talked about the concept of “silence means no.” People will often be silent when they don’t want to say no, especially if they are afraid of offending someone or voicing what might be an unpopular opinion, so it can be a better strategy to consider it a no rather than forcing something through that might not have support from the community.

Collider

The infrastructure requirements at CERN, which runs The Large Hadron Collider among other projects, is massive, and so automated configuration management is a must. From a configuration management perspective, systems engineer Nacho Barrientos talked about how CERN uses Puppet with roughly 24,000 active nodes in PuppetDB, 270 catalogs compiled per minute, 191 changes per day, and 384 modules. The ops teams could do all of this work in isolation, but instead, they choose to share information and actively participate in the community.

The CERN Configuration Management System User Guide is publicly available and contains a wealth of information about how CERN does infrastructure automation. The organization also has a CERN ops GitHub organization with dozens of public repositories. But in addition to sharing code and information, CERN engineers are also active contributors back to the upstream projects for the Foreman lifecycle management tool, jRuby, modules, and Puppet core because they see the value in participating in the wider configuration management community.

Even the presentations about using specific tools including discussions about community. Red Hat configuration management architect  James Shubin (Red Hat) talked about mgmt, a next generation configuration management tool, which has had quite a few contributions from other people within the community already. He encouraged people to join the project to help with things like building the Domain Specific Language (DSL).

Netways’ Dirk Götz  talked about how Foreman is more than a Puppet dashboard by emphasizing how it can be extended to integrate with other open source projects, including Ansible, Chef, Salt, Docker, and he provided more with information about how to participate in the community. Chef’s Vice President of Community Development Nathen Harvey (Chef) ended his talk about Habitat with the call to action, “Let’s build together” and a link to the community page for Habitat.

Where the Berlin camp was a single track, one-day event, the next Config Management Camp is a two-day, multi-track event being held in Ghent, Belgium Feb. 6 – 7.

Disclaimer: Dawn Foster worked at Puppet from 2012 through 2015 and currently owns stock in Puppet.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.