[Vote ended on 2024-10-07] Should we remove community.network from the Ansible community package?

At today’s community meeting we were talking (again) about tests for all collections included in the Ansible community package, from where the discussion ended up with community.network.

Right now community.network is not actively maintained (there’s basic maintenance done by @Andersson007, but that’s basically it). The last feature release was in 2022, and in the last 12 months there only have been a few bugfixes.

There seem to be some users of that collection, but there don’t seem to be many (or none at all?) active module maintainers anymore. The last batch of reported sanity errors (Community package requirements: sanity tests · Issue #591 · ansible-collections/community.network · GitHub) is basically still there, since nobody wants to work on them.

One thing that might still be used more are redirects in meta/runtime.yml. There are 46 redirects to other collections, but more than half of these go to community.fortios, which we already removed from the Ansible community package, and several more to cisco.nso (which we also removed). Then there are a few redirects to community.routeros, and one to fortinet.fortimanager (for a httpapi plugin). So from the redirects, only community.routeros users might suffer from short names no longer working. (Whether anyone is still using the community.routeros shortnames is another question.)

So, what do you think? Should we keep it? Remove it? Or are you even an active user of something that’s included in community.network? Please tell us :slight_smile:

1 Like

I support removing the collection due to lack of maintenance and activity. Even the issue tracker on the collection is pretty light which does not point to the collection having many active users — or at least users who are interested in participating upstream, which is what the collection needs to survive.

I want to stress that I appreciate the work that members of the Community Team (including @Andersson007) have done to the keep the collection afloat, but the collection really needs a group of devoted maintainers who use the different modules and plugins and are familiar with the services that they interact with. My understanding is that most of the original authors of the plugins are not maintaining them anymore.

I do support moving content out of the community.network collection, even to collections that are not part of the Ansible package, provided that the removals are properly communicated in the changelog.

1 Like

@felixfontein @gotmax23 how you folks summarized it all sounds fair. I don’t remember any original authors/maintainers ever responded to bot’s/mine pings… I go there from time to time to fix CI (thanks for reminder) and extremely rarely (due to a lack of changes) release it.
I support its removal from the package.
It’s been there long enough to provide backwards-compatible move after the ansible/ansible repo split.
Now everyone is aware of collections so they can install it manually if needed or move a part of its content to their own collection.

As a side-note: removing the collection from Ansible also removes the current block on removing content from the collection to outside the Ansible community package.

Also currently there are a few deprecations with removal in 8.0.0 in meta/runtime.yml; 8.0.0 there was chosen assuming that there’s a major release every 6 months, which didn’t happen for quite some time now. I guess we should modify the 8.0.0 to 6.0.0 (the next major release, whenever / if ever it comes), otherwise these redirects will still be there in 20 years :wink:

1 Like

I posted a link to this in Status of `community.network` · Issue #616 · ansible-collections/community.network · GitHub also.

1 Like

In that case, why not deprecate the collection officially due to the lack of someone maintaining it? And then we remove it, similar to frr.frr and openvswitch.openvswitch.

2 Likes

Yep, i believe that’s the way to go

I would probably give folks a few weeks to react, and if nobody does, deprecate and start the removal process.

1 Like

As far as I can see, this discussion will be mentioned in the next Bullhorn. Let’s wait until this has been released and then two or three weeks more so people can react?

4 Likes

FYI - was mentioned here in the Bullhorn on Aug 26.

Discussed in WG meeting today:

  • Removing from the package for Ansible 11 (if that’s allowed?)
  • Set a time to deprecate the collection itself so it can eventually go unmaintained after some final release.

So what does the plan exactly look like?
I think we should:

  1. vote on removal
  2. if positive, proceed with removal according to the removal process

Are we ready to start the poll?

I guess it would be best if the collection would declare its deprecation because no one is actively maintaing it itself on Bullhorn to begin with. Like frr.frr and openvswitch.openvswitch did. Ideally mentioning that This collection is not supported with ansible-core>2.17 or There will be no work done on making this collection work with ansible-core>2.17 or similar.

I don’t want to do this because I haven’t worked on this collection at all. I suggest someone who has worked on this collection recently (hint hint @Andersson007).

This would change the situation considerably for us. We wouldn’t start a vote on a collection that’s considered unmaintained or that we know is unmaintained, but on one that declared itself unmaintained. And denies compatibility with / supporting ansible-core 2.18, which the next Ansible Community Package will be based on.

How about:

  1. Announce it again in The Bullhorn, to increase the chance that users saw it.
  2. If there is still no reaction in 1-2 weeks, start a vote on deprecating the collection. Since community.network and community.general are officially governed by the SC the SC should officially decide whether they should be deprecated.
  3. Once it’s deprecated, announce that in the Ansible changelog, including the removal of the collection from Ansible 11 (Ansible Community Package Collections Removal Process — Ansible Community Documentation).
1 Like

I’ve just announced it, i.e. point 1 is done.
So next:

  • 1. If there is still no reaction in 1-2 weeks, start a vote on deprecating the collection. Since community.network and community.general are officially governed by the SC the SC should officially decide whether they should be deprecated.
  • 2. Once it’s deprecated, announce that in the Ansible changelog, including the removal of the collection from Ansible 11 (Ansible Community Package Collections Removal Process — Ansible Community Documentation).
1 Like

I agree, let’s wait another 1-2 weeks. But when we start a vote, we should make clear that it’s both about deprecating the collection itself and removing it from Ansible 11.

BTW when do we want to remove it? We said beta1 is a feature freeze release, so I guess we have to do it before this. Correct?

Should we aim to remove it already in alpha1? I’m not sure if we have enough time since ETA is in 2 1/2 weeks, though.

2 Likes

According to our process (Ansible Community Package Collections Removal Process — Ansible Community Documentation) removing it before feature freeze (beta 1: Ansible project 11.0 — Ansible Community Documentation) is fine. It would be great to remove it as early as possible (and also announce removal from 11 in the 10 and 9 changelogs as early as possible). Assuming we now wait 2 weeks, and run the vote for 1 week, we’ll still get this done in September, which is more than a month before feature freeze (and also still before alpha 2).

2 Likes

Announced again in The Bullhorn #152 on Sep 6.

1 Like

I’m active user of community.network and community.routeros and currently looking at fixing support for some Ubiquiti devices so particularly interested to see how this plays out.

That said removing from community collection seems OK and a managable change to make for us and other end users.

1 Like

Just a fyi for people who want to start maintaining a part of community.network but not the whole collection that we’d be happy:

  • If you request a repository under the ansible-collections org
  • We’ll copy the content you’re interested to maintain
  • We’ll give you permissions in the repo
  • If it goes well, we could deprecate corresponding stuff in community.network
  • The new collection can get included in the ansible package if it passes the inclusion process

See the Maintainer guidelines to learn about maintainer responsibilities.

2 Likes