Proposal: Introduce a new Ansible Operator base image for Ansible core 2.11 and beyond #5115
Description
Feature Request
Describe the problem you need a feature to resolve.
In the past 18 months or so, the Ansible core engine has gone through a dramatic transition in how it is developed, packaged and distributed. Ansible has followed a "batteries included" approach including all of its content (modules and other plugins) in one repo and distribution since its inception through version 2.9, currently used by the Ansible Operator base image.
Beginning with version 2.10 (released as a tech preview), all modules and plugins were removed from the Ansible core repository into their own independent repos. All content going forward is packaged as Ansible Content Collections, or “collections” for short. Collections are a new format for organizing Ansible content independent of the ansible core project.
Most relevant to the Operator SDK is the changes in how Ansible is packaged and distributed. There is now a community distribution that has taken over the ansible package seen in PyPI that attempts to approximate the batteries included distro of versions past.
So one option is for the Operator SDK to use that distribution, but I don't recommended doing that. I believe there is a more beneficial approach the project should adopt. That approach is to build a "new style" of Ansible base image with the latest stable core and a select group of collections and their dependencies that an Ansible Operator developer will commonly need and use.
Describe the solution you'd like.
I suggest this project consider taking advantage of this new flexibility in the distribution and packaging of Ansible core engine functionality by adopting a leaner and more streamlined Ansible base image built specifically for the needs of Ansible Operator developers.
With thousands of modules that are rarely if ever removed the image will be a bit smaller. This would allow this project to focus on a subset of Ansible and provide a complete implementation of what is included. While the batteries-included distro included thousands of modules, many of them had python library and CLI dependencies that are not included.
This new image would include the latest stable core engine and a select group of collections and along with any dependencies that are likely/commonly needed.
- ansible.core
- kubernetes.core
- operator-sdk.util
This image would also include the Ansible Operator SDK Go binary and python itself and any additional packages required by Ansible and these collections such as the Kubernetes Python Client etc. (Previously kubernetes.core used the openshift rest client library, but, beginning with 2.0, the collection has refactored its code that only the official Kubernetes client for python is required.)
Also required is the helm CLI (the helm modules in kubernetes.core wrap it) and I would highly recommend the helm-diff plugin be included in this base image. This would provide a means of porting a Helm operator to a more functional and flexible Operator using the Ansible Operator SDK.
This is not a final or complete list. If accepted by the community, additional consideration and review of what is included should be conducted during development.
There are some drawbacks that need to be considered here.
-
There is a bit more work involved to build and distribute the image to assemble all of the Ansible content. The Ansible project has produced a tool called ansible-builder to create container builds that should be explored as a potential means for building the base image. For more on ansible-builder see this Ansible blog post on it.
-
Some operators may be using modules included in the batteries included distro that will no longer be included in the streamlined base image. I don't think there is a way of knowing the extent of this issue. The potential is there with thousands of modules. There is a very clear work around to this -- install the missing collection with the modules they are missing. The project would need to clearly communicate and document what is in the base image and how developers can add additional collections and their dependencies to their Operators.
-
There would need to be a deprecation and transition process implemented to gradually introduce this "new style", maintaining a 2.9-batteries-included image and a 2.11-streamlined image simultaneously. The project may want to consider introducing the latter as a tech preview or beta to get more feedback on the image's manifest.
I welcome your comment, questions and feedback on this proposal.
/language ansible