CfgMgmtCamp 2026 discussion (11/12): Features are removed without public discussion or known good reason

Project Discussions Collection Development
, , ,
1

As a collection developer/maintainer

Features are removed without public discussion or known good reason

Latest developments

None that I know of. This wasn’t discussed at CfgMgmtCamp 2026.

Original text

This one is very specifically about attributes for role entrypoints (and a very personal one from me). The attribute feature allows to document a dynamic set of properties for modules, plugins, and role entrypoints in a uniform way (original proposal, implementation). Every attribute has a name, a description, and a supported value (full / partial / none / N/A) with optional details. This is extensively used in the ansible.builtin documentation, and to some lesser extend also in collection documentation.
(They are used for check mode, diff mode, action group support, to indicate returning of facts, and in some cases to document supported platforms in community.general, for example.)

When the attribute feature was introduced, it was explicitly implemented for modules, plugins, and role entrypoints. (Modules and plugins are handled by one code path, role entrypoints by another.)

Then, at some point, support for role entrypoints got simply removed as a by-product of implementing another feature. I created an issue that it got removed. The comment from Core was “I thought that was a typo, how are attributes being used in roles?”, despite roles being explicitly and separately (from modules and plugins) being implemented before. The Core team declared that implementing it has been a mistake / that it is an unexpected feature. At least they agreed to properly deprecate it before removal (PR to re-add). There has been no public discussion, the documentation working group (DaWGs) was not involved in this decision at all, and I still haven’t seen any valid argument for why this is an unwanted feature that should be removed.

I’m still using it and I will not stop using it just because the Core team thinks it shouldn’t be there. The reason why attributes are useful for plugins and modules also applies to role entrypoints.

Antsibull-docs will keep supporting it, and I encourage everyone to keep using it to improve role documentation.

1 Like
CfgMgmtCamp 2026: Community and Contributor Summit
The Bullhorn #218
CfgMgmtCamp 2026 discussion (0/12): Problems in the Ansible world and how to improve on them
2

fwiw, this is not how the core team works, or necessarily intends to work. All decisions about the direction of core and what is and isn’t considered a feature or something we are willing to support comes down to the sole decision of the core team. This has always been the case with the governance model of ansible-core.

I know an official statement of the core governance model isn’t really available anywhere, but I’ll share the draft statement I’ve had sitting around:

The Ansible Core project is governed by, what is often referred to as, an Oligarchy.

The governing body, or oligarchy, is composed of the Ansible Core Team. The Core team operates internally by means of consensus.

While all Core Team members may have individual opinions, all topics requiring larger Core Team support will generally be assigned delegate or representative, who will relay the decisions of the Core Team consensus. Often the Core Team may participate in public discussions, but will generally also have discussions in internal forums to make decisions that will be relayed publicly by the Core Team Delegate.

Within this governance model, there is also Red Hat Product and the Open Source Community. These two bodies are considered to be key stakeholders, and are consulted for direction and functionality. These bodies relay their requests to the Core Team, who is ultimately responsible for approval, and prioritization.

Aside from that, we do now have documentation stating that “emergent features” may be removed at any time without announcement or deprecation. The roles attributes were deemed to be an emergent feature that was not explicitly designed, and one we did not feel was well aligned with roles.

1 Like