# \[Vote ended on 2024-11-05\] Unmaintained collection: netapp.storagegrid **URL:** \ **Category:** Project Discussions\ **Tags:** community-wg, collections\ **Created:** [December 8, 2023, 4:01pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811 "2023-12-08T16:01:35Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [December 8, 2023, 4:01pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/1 "2023-12-08T16:01:36Z")
The [netapp.storagegrid](https://github.com/ansible-collections/netapp.storagegrid) collection looks unmaintained / abandoned, it has: - no new commits since September 2022 - no new release since [Sep 24, 2022](https://github.com/ansible-collections/netapp.storagegrid/releases) - failing CI pipeline since [Nov 2, 2022](https://github.com/ansible-collections/netapp.storagegrid/actions/runs/3375281273) and no CI run since [Dec 3, 2022](https://github.com/ansible-collections/netapp.storagegrid/actions/runs/3607309874) - tests defined up to ansible-core 2.13 but not with the current release ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [December 16, 2023, 2:13pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/2 "2023-12-16T14:13:43Z")
For the record, [someone says that the collection is still maintained](https://github.com/ansible-collections/netapp.storagegrid/issues/22#issuecomment-1854652020). Well, let’s see what they say about the failing / not running CI and that it doesn’t test with ansible-core \> 2.13. ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [February 4, 2024, 6:21pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/3 "2024-02-04T18:21:04Z")
I’d like to vote on removing this collection from Ansible 11 since it looks unmaintained. The vote will end 2024-02-17. _Poll ([view on site](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/3))_ _Poll ([view on site](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/3))_ ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [February 17, 2024, 6:38am UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/4 "2024-02-17T06:38:55Z")
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. ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [February 25, 2024, 12:48pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/5 "2024-02-25T12:48:06Z")
[@SteeringCommittee](https://forum.ansible.com/groups/steeringcommittee) Does [this](https://github.com/ansible-collections/netapp.storagegrid/issues/22#issuecomment-1962770233) 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: 1. CI fails for ansible-core 2.16 2. They’ve dropped support for ansible (core) \< 2.14, but didn’t announce it in the changelog 3. They’ve dropped support for ansible (core) \< 2.14 in a minor release (21.12.0 instead of 22.0.0) 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. ---
**Author:** ![Andersson007](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/andersson007/32/89_2.png) [@Andersson007](https://forum.ansible.com/u/Andersson007)\ **Post date:** [February 26, 2024, 9:49am UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/6 "2024-02-26T09:49:36Z")
> 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:) ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [February 26, 2024, 5:56pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/7 "2024-02-26T17:56:29Z")
> [@Andersson007](#): > > > 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? 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. ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [February 26, 2024, 7:49pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/8 "2024-02-26T19:49:49Z")
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. ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [February 26, 2024, 7:55pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/9 "2024-02-26T19:55:55Z")
> [@mariolenz](#): > > [@SteeringCommittee](https://forum.ansible.com/groups/steeringcommittee) Does [this](https://github.com/ansible-collections/netapp.storagegrid/issues/22#issuecomment-1962770233) count as `One or multiple maintainers step up, or return, to clean up the collection's state`?. 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). > [@mariolenz](#): > > 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. 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… ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [February 26, 2024, 9:32pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/10 "2024-02-26T21:32:09Z")
> [@felixfontein](#): > > Failing CI isn’t a good sign (of course it depends on _why_ it fails). 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… ---
**Author:** ![joshedmonds](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/joshedmonds/32/2414_2.png) [@joshedmonds](https://forum.ansible.com/u/joshedmonds)\ **Post date:** [February 27, 2024, 1:55am UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/11 "2024-02-27T01:55:00Z")
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. ---
**Author:** ![carchi8py](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/carchi8py/32/3762_2.png) [@carchi8py](https://forum.ansible.com/u/carchi8py)\ **Post date:** [October 30, 2024, 4:14pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/12 "2024-10-30T16:14:31Z")
@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. ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [October 30, 2024, 5:38pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/13 "2024-10-30T17:38:15Z")
@carchi8py thanks for writing! The process is explained here: [Ansible Community Package Collections Removal Process — Ansible Community Documentation](https://docs.ansible.com/ansible/devel/community/collection_contributors/collection_package_removal.html#canceling-removal-of-an-unmaintained-collection) Please note that the Ansible 11 feature freeze is beginning of next week ([Ansible project 11.0 — Ansible Community Documentation](https://docs.ansible.com/ansible/devel/roadmap/COLLECTIONS_11.html#release-schedule)), so this is all very tight. ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [October 30, 2024, 7:12pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/14 "2024-10-30T19:12:25Z")
> [@carchi8py](#): > > 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 Just FYI `netapp.cloudmanager` is also on my current list of [possibly unmaintained collections](http://forum.ansible.com/t/9300). I didn’t start any formal process on this since Ansible 11.0.0 hasn’t been released yet, though. ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [October 30, 2024, 8:58pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/15 "2024-10-30T20:58:06Z")
@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. ---
**Author:** ![carchi8py](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/carchi8py/32/3762_2.png) [@carchi8py](https://forum.ansible.com/u/carchi8py)\ **Post date:** [October 30, 2024, 10:48pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/16 "2024-10-30T22:48:01Z")
For Cloudmanager let me get back to you tomorrow when I meet with the team on that. ---
**Author:** ![carchi8py](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/carchi8py/32/3762_2.png) [@carchi8py](https://forum.ansible.com/u/carchi8py)\ **Post date:** [October 30, 2024, 10:51pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/17 "2024-10-30T22:51:39Z")
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. ![Screenshot 2024-10-30 at 3.49.51 PM](https://us1.discourse-cdn.com/ansible/original/2X/1/1411f491904d98deeeec98dfb391dca614485281.png) ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [October 31, 2024, 4:16pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/18 "2024-10-31T16:16:42Z")
> [@carchi8py](#): > > For Cloudmanager let me get back to you tomorrow when I meet with the team on that. 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 😏 ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [October 31, 2024, 6:02pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/19 "2024-10-31T18:02:56Z")
> [@felixfontein](#): > > 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. [Collections MUST adhere to the Semantic versioning conventions](https://docs.ansible.com/ansible/latest/community/collection_contributors/collection_requirements.html#versioning-and-deprecation) ---
**Author:** ![carchi8py](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/carchi8py/32/3762_2.png) [@carchi8py](https://forum.ansible.com/u/carchi8py)\ **Post date:** [October 31, 2024, 6:29pm UTC](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811/20 "2024-10-31T18:29:21Z")
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](https://github.com/ansible-collections/netapp.storagegrid/releases)). 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. [Next page](https://forum.ansible.com/t/vote-ended-on-2024-11-05-unmaintained-collection-netapp-storagegrid/2811.md?page=2)