Should we allow moving content out of community.general and community.network to collections that are not part of Ansible?

Quoting myself from https://github.com/ansible-community/community-topics/issues/167:


In the past we actively decided not to allow this, but I think it’s time to rethink this, especially since we are removing collections from Ansible that are unmaintained, and having things in c.g/c.n that are not maintained in that place anymore moved somewhere else where it is maintained is a lot better IMO than keeping a unmaintained copy just for sake of not breaking playbooks when users do pip install --upgrade ansible. Users can easily install the additional collections they need.

A concrete case where this came up is Removal of avi modules from community.network by chandanapatnala · Pull Request #506 · ansible-collections/community.network · GitHub - the avi_* modules are pretty unmaintained there (the only change so far was fixed: variable 'rsp' referenced before assignment by rothman857 · Pull Request #218 · ansible-collections/community.network · GitHub), but vmware.alb is available on Galaxy with the same modules (apparently), and its actively worked on.

So my proposal would be: allow to move content out of c.g and c.n to other collections outside of Ansible, assuming it is announced in time (roughly half a year before the actual remove happens, i.e. announcing now that removal will happen in the next major release which is close to the next Ansible major release is fine).

What do you think, is this good enough to vote on, or do you have other ideas, comments on this, …?


If nobody beats me I’ll eventually combine the last few comments here into a new proposal. For now I’m keeping just this stub so this disucssion doesn’t get lost.

3 Likes

The following is an updated version of my proposal from Should we allow moving content out of community.general and community.network to collections that are not part of Ansible? · Issue #167 · ansible-community/community-topics · GitHub,

We allow to move content out of c.g and c.n to other collections outside of Ansible under the following conditions:

  1. The new collection is appropriately licensed and does not require a CLA to contribute.
  2. None of the contributors who contributed to the content in the last 6 months objects in a four-weeks period after the plan to deprecate the module has been announced.
  3. There is a deprecation period of at least 6 months during which deprecation warnings are shown. The deprecation notice must mention that the content is moved to a collcetion outside the Ansible community package, and that users need to install that collection separately.
  4. If community members or contributors bring up good reasons in these 6 months to not do the move, the Steering Committee will discuss these and vote on them before the content is removed.

Redirects are only added if full backwards compatibility can be ensured. If they are not used, tombstoning has to be used, and the tombstone message needs to explicitly mention the new collection and that the content in the new collection is not fully backwards compatible.

What do you think, in particular @SteeringCommittee? Does this sound reasonable / acceptable / …?

1 Like

Does it really need to be a requirement to move them into another collection at all? What if it’s not maintained, and no one really wants it?

I’m fine with allowing things to move out, I just wouldn’t make it a requirement that it needs to go somewhere. It could just get deleted, and it lives in an old branch, if someone wants it later, they could always just pull it into another collection.

1 Like

It’s not a requirement at all; collections can deprecate and tombstone content whenever they want. We have no rule against that. But we do have a rule that you cannot move content to a collection that’s not part of the community package.

I think the ideas behind this were to

  1. motivate that collections where content is moved go through the review process and will also be included, and
  2. improve the user experience by ensuring that redirects introduced in collections contained in the community package again point to the community package.

(I guess we started violating the idea behind 2) a bit ourselves by excluding collections from Ansible in the past.)

1 Like

Coming to this one a bit late. I think in the case that a module is unmaintained in c.g or c.n , yes definitely we should allow it to be moved to a non-Ansible-package collection.

For the example where there is now duplicate development on a module - again, feels like your set of proposed guidelines works well and will eventually resolve this problem.

So my non-SC opinion is … start the vote on this one!

1 Like

I’m still waiting for more @SteeringCommittee opinions here for my proposal. Does nobody have any opinion on this?

Long story short: I think it’s better to have maintained content (modules, inventory plugins, whatever) in a collection that’s not part of the Ansible Community Package than having unmaintained content there. The latter sounds like an accident waiting to happen.

If there’s an alternative in another collection, I tend to deprecate and remove the content from c.g / c.n even if this collection isn’t included in ACP.

DISCLAIMER: I’m not involved in c.g / c.n. People who are might think differently and, if they do, I don’t want to contradict them and would follow their lead.

2 Likes

I am involved in c.g and I second @mariolenz on that assertion. I think ACP is bloated as it is and cat-herding doing quality assurance for all those collections is not really feasible.
I say we should take any and every opportunity to make the ACP package leaner, but I am aware this opinion is not shared by many, so not pressing on it.
For this specific case, I would cast my vote on not keeping the code within c.g/c.n collections.

I support allowing content to move from collections in the ACP into collections outside the ACP.

When most modules migrated into collections and we moved away from the “everything-included” model of Ansible, the promise to the community was that the move would maintain pre-existing functionality for pip install ansible.

Today the collections model is mature, and at least some of the modules included in the community collections are outdated (either because the module code is old/unmaintained, or because the tasks the module performs are less relevant, or both). We can migrate little-used modules out of the ACP, either by removing them entirely, or by moving them to collections that are not included in the package. There is a well-documented path to reinstating them, if someone wants to follow it.

I created a proposal for how this can look concretely in the requirements: [WIP] Add rules on moving content to collections outside of Ansible by felixfontein · Pull Request #1971 · ansible/ansible-documentation · GitHub

(While doing that I noticed that the current rules aren’t explicitly written down. Or at least I was unable to find them. If anyone finds them, please point me to them :slight_smile: )

Please add your comments / suggestions to the PR. If there are no more suggestions / discussion for a few days, I’ll start a vote.