The netapp.storagegrid collection looks unmaintained / abandoned, it has:
For the record, someone says that the collection is still maintained. Well, let’s see what they say about the failing / not running CI and that it doesn’t test with ansible-core > 2.13.
I’d like to vote on removing this collection from Ansible 11 since it looks unmaintained. The vote will end 2024-02-17.
The vote ended today. 9 steering committee members voted, and all are in favor of removing netapp.storagegrid from Ansible 11. No one voted to keep the collection. This means we’ve reached the quorum and the vote is accepted.
There were no votes from the community, neither in favor of nor against it.
@SteeringCommittee Does this count as One or multiple maintainers step up, or return, to clean up the collection's state?. I should think so, but I also think there are still some problems:
Anyway, are they even using semver? After 20.11.0 they’ve released 21.6.0. Isn’t semver a requirement? I’m a bit confused about their versioning at the moment.
Isn’t semver a requirement?
Looks like it’s a MUST. I remember there were talks about it in the context of the netapp collections years ago but i don’t remember any details… @felixfontein maybe you have any memories on that? Anyway, we should do something: 1. ask them to comply 2. change MUST to SHOULD. 3. accept another versioning convention, like that one with YY-*…
They’ve dropped support for ansible (core) < 2.14 in a minor release
Isn’t it OK if it doesn’t necessarily imply breaking stuff? e.g. when we just stop testing against it? If in their case it breaks stuff, that’s definitely not acceptable:)
I think this isn’t documented somewhere and there are different opinions. I tend to the view that dropping support is a breaking change because might mean users can’t update to a new minor (or even bugfix) release without also updating ansible-core to a new major version.
But, as I’ve said, I think there are different opinions on this.
Semver is a MUST from our side since Ansible itself is semver, so we must be able to rely on collections to also follow semver.
Removing support for ansible-core versions is something where multiple opinions exist. Unfortunately ansible-galaxy collection install does not handle supported ansible-core versions similar to pip handling supported Python versions, so I would argue that dropping ansible-core support is a breaking change. I know that plenty of other folks (both from RH and community) see it differently. Also there’s a difference between not supporting a specific ansible-core version (i.e. no longer test against it, so accidental incompatibilities are possible), and actively not supporting it (by actively removing code that’s needed to support it). I guess the former is a gray area…
In any case, since these requirements are for building Ansible, dropping support for older ansible-core versions (that are no longer supported by the supported Ansible releases) should not really concern us, since that isn’t a breaking change for Ansible itself - it ships a modern enough ansible-core.
So from that point, I would say semver is a MUST, but dropping support for older ansible-core versions is a kind of acceptable semver violation, at least for inclusion in Ansible.
I think that one counts, but there’s still point 3:
There have been concrete results made by new maintainers (for example, CI has been fixed, the collection has been released, pull request authors have got meaningful feedback).
Failing CI isn’t a good sign (of course it depends on why it fails).
I don’t think semver says that you need to release 21.0.0 before you release 21.6.0, though it’s not very common. Maybe they synchronize version numbers with something else? Or they use calver for new major releases, and then switch to regular semver? I do remember there has been a discussion about their versioning scheme, but I don’t remember the details…
It doesn’t look like the code is bad. Looks more like a problem in their CI workflow for me. But why did they commit and release if the CI fails? I don’t like it…
Hi, I’ve been working on bringing this collection back in line to avoid it being removed and will try to address some of these outstanding questions.
Previously the various NetApp collections used CalVer (YY.MM.PATCH) until SemVer was enforced. I don’t fully remember the details, but to avoid issues with collection upgrades, “21” remained as the Major version number. It’s consistent across all NetApp Ansible collections I believe.
I agree regarding the failing CI workflows - currently discussing with another maintainer and will work on clearing the errors. My main priority was ensuring it passed with 2.14 and 2.15.
@mariolenz what would be the steps to get this collection back in to ansible?
The Netapp Ansible team that maintains the other Netapp collections has taken ownership and we are planing to have new release every 2 months start in December.
@carchi8py thanks for writing! The process is explained here: Ansible Community Package Collections Removal Process — Ansible Community Documentation
Please note that the Ansible 11 feature freeze is beginning of next week (Ansible project 11.0 — Ansible Community Documentation), so this is all very tight.
@carchi8py Just FYI netapp.cloudmanager is also on my current list of possibly unmaintained collections.
I didn’t start any formal process on this since Ansible 11.0.0 hasn’t been released yet, though.
@carchi8py would it be possible to get a new release of netapp.soragegrid out by the end of this week that has working tests for ansible-core up to 2.18? That would be a great signal, and then we could try to have a quick vote until Tuesday morning to revert the removal before feature freeze.
For Cloudmanager let me get back to you tomorrow when I meet with the team on that.
For StorageGrid i can get the test fixed this week, we can do a real with the small fix that were required for that.
We have our own internal dev branch in Bitbucket works with the new pipeline change and 2.18 working. So I should be able to get that out tomorrow or early friday.
Take your time. We didn’t even start discussing about netapp.cloudmanager. A new netapp.storagegrid release that has working tests for ansible-core up to 2.18 until the end of the week looks more important to me 
So way way way back in the day before Sematic Versioning was required we were doing
YY.MM.PATH
In 2021 when Sematic Versioning was required we used what ever the current release and made that major.minior patch and went from there (So we didn’t end up with lower numbers). So that why the release have high Major number at the moment like 21.12.0 (Releases · ansible-collections/netapp.storagegrid · GitHub). We didn’t want to reset it to 1 or a lower number so we took 21 as the major release and incremented from there.
So both are Cloudmanager and StroageGird are following Sematic versioning since 2021.
