Ansible extends time between upgrades, space between core and community modules

Ansible extends time between upgrades, space between core and community modules

Ansible fans will have to wait a little longer for upgrades to the Red Hat/IBM-owned automation platform in the future, as it overhauls the way it delivers its core software and manages an array of outside modules and plug-ins.

In a blog outlining the new philosophy, the Ansible community team wrote, “We now find ourselves dealing with problems of scale that are becoming more challenging to solve.” 

A large part of the problem is that most Ansible’s own team finds it increasingly difficult to offer (paid) support for the entire range of community modules in its universe. On top of that, they continue, some contributors are more responsive than others, while the team was also grappling with the problem of how to ensure better quality modules, particularly when it comes to new contributors.

Things are further complicated by the fact that “As Ansible itself becomes more mature and used by more enterprise customers, the lifecycle of Ansible is slowing down.” While Ansible traditionally shipped a new version every four months, the most recent one took eight months, “and that slower release cycle will become the rule”.

The community team said it would break out Ansible into a number of components. The core engine will “essentially be the platform to run everything else. Keeping this engine stable, more secure, and well-tested will be critically important for everyone.”

The most used modules and plugins will become Core modules and plugins which will be supported directly by the Ansible team. Meanwhile, most “non-core”modules and plugins will be designated “community”. Contribution policies for these will be “relaxed to some degree to help onboard new content and new contributors”.

Meanwhile, some supported partner modules and plugins will be “broken out and managed more directly by partners” with community contribution policies left up to the individual maintainers.

In future, Ansible will be delivered in two ways. A “batteries included method” will bundle the core engine, official modules and plugins, all the community modules and plugins and selected partner modules and plugins – but will not have Red Hat support.

Red Hat will offer support as part of a “supported enterprise method” for a bundle encompassing core modules and plugins, and select partner modules and plugins. Customers choosing this will be still be able to install other modules, etc.

That said, the team added, “None of these changes are imminent, but we believe that we’ve come to a point at which we are prepared to discuss the possibilities.”

These will all be delivered as “Ansible Content Collections” – a concept first aired with the 2.8 release back in May, and trailed by Tim Appnel, senior principal product manager for Ansible back in January.

Ansible is hardly alone is having to reconcile the demands of maintaining a stable code base for enterprise customers, and the challenges of managing an eclectic range of add-ons and modules. Jenkins went through similar soul searching a few years ago, as indeed did Ansible’s parent Red Hat before the creation of the Fedora project and Red Hat Enterprise Linux.