Finding unmaintained collections in Ansible

[mariolenz]

Summary

I am not aware that we have a way to detect unmaintained collections. Therefor, I've written a small script to compare dependencies between versions. The idea is that if a collection version didn't change between, say, 3.0.0 and 6.2.0, this collection might be unmaintained.

Do you think this might be useful? If so, where should we put it? It has to be run in the ansible-community/ansible-build-data directory, so we could add it to this repository directly. Or do we have another repo for tools concerning the community package where we can add it?

Of course, this question only arises if you consider this useful. If not, we don't have to discuss where to put this script.

Result of running unchanged-dependencies.py 6.2.0 3.0.0:

cisco.nso
community.fortios
community.google
community.skydive
cyberark.conjur
dellemc.os10
google.cloud
mellanox.onyx
ngine_io.exoscale

unchanged-dependencies.py:

#!/usr/bin/python
# coding: utf-8
# Author: Mario Lenz <[email protected]>
# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt)
# SPDX-License-Identifier: GPL-3.0-or-later
# SPDX-FileCopyrightText: Ansible Project, 2022
"""Show unchanged dependencies between Ansible versions."""

import argparse


def get_dependencies(version):
    dependencies = {}
    major_version = version.split('.')[0]
    with open('%s/ansible-%s.deps' % (major_version, version)) as f:
        for line in f:
            dependency = line.strip().split(':')
            dependencies[dependency[0]] = dependency[1].strip()
    return dependencies


def compare_dependencies(dependencies1, dependencies2):
    for dependency in dependencies1:
        if dependency in dependencies2:
            if dependencies1[dependency] == dependencies2[dependency]:
                print(dependency)


def main():
    parser = argparse.ArgumentParser(description='Show unchanged dependencies between Ansible versions.')
    parser.add_argument('version1', help='first version for the comparison')
    parser.add_argument('version2', help='second version for the comparison')
    args = parser.parse_args()
    dependencies1 = get_dependencies(args.version1)
    dependencies2 = get_dependencies(args.version2)
    compare_dependencies(dependencies1, dependencies2)


if __name__ == '__main__':
    main()

[mariolenz]

@Andersson007 Looking at the output of my example, it looks like you've released dellemc.os10 v1.2.0 but I don't see it on galaxy. And, therefor, it's not part of the community package.

[felixfontein]

I looked through the list, here are my guesses:

Officially unmaintained:

• google.cloud (we decided that :) )

Seems unmaintained, parts might no longer work:

• community.skydive (Private argument spec validation methods no longer available in Ansible Core 2.11 ansible-collections/skydive#17 (comment))

No activity (including no bug reports and PRs) - i.e. might simply be working without need of changes:

• community.fortios
• community.google
• cisco.nso
• ngine_io.exoscale

Not sure:

• mellanox.onyx (https://github.com/ansible-collections/mellanox.onyx/commits/master, Update mellanox.onyx collection on Ansible Galaxy ansible-collections/mellanox.onyx#24)

Actively maintained (just no release):

• cyberark.conjur (https://github.com/cyberark/ansible-conjur-collection/commits/main)
• dellemc.os10 (https://github.com/ansible-collections/dellemc.os10/commits/master)

[felixfontein]

Regarding the script: I guess it would make sense to integrate that into antsibull. I'm not sure how exactly though (i.e. whether as a subcomand of antsibull-build, or as a new CLI tool).

[mariolenz]

Officially unmaintained:

• google.cloud (we decided that :) )

Yes, I know. But if I haven't included this people would have asked why my script didn't find out why google.cloud hasn't changed since 3.0.0 ;-)

Actively maintained (just no release):

• cyberark.conjur (https://github.com/cyberark/ansible-conjur-collection/commits/main)

cyberark/ansible-conjur-collection#175

• dellemc.os10 (https://github.com/ansible-collections/dellemc.os10/commits/master)

It looks like @Andersson007 tagged a new release v1.2.0 but somehow it's not on Galaxy.

[Andersson007]

@Andersson007 Looking at the output of my example, it looks like you've released dellemc.os10 v1.2.0 but I don't see it on galaxy. And, therefor, it's not part of the community package.

@mariolenz yep, i know, the collection was forgotten at that time (now maybe it is too). We had merged several PRs with independent folks and I released the collection as maintainers had not responded.. After that we noticed that it hadn't appeared on galaxy automatically which means they hadn't publish it via Zuul. IIRC finally someone appeared promising to release publish it on Galaxy.
If it still hasn't happened, we could consider it unmaintained.

[mariolenz]

yep, i know, the collection was forgotten at that time (now maybe it is too).

@Andersson007 Not only dellemc.os10. If I use my script to compare 6.2.0 against 4.0.0 (instead of 3.0.0), there are also dellemc.os6 and dellemc.os9 on the list of collections that that are still the same version.

If it still hasn't happened, we could consider it unmaintained.

I think that dellemc.os6 and dellemc.os9 might be possible candidates, too. All commits from this year are from you ;-P

[mariolenz]

Not sure:

• mellanox.onyx (https://github.com/ansible-collections/mellanox.onyx/commits/master, Update mellanox.onyx collection on Ansible Galaxy ansible-collections/mellanox.onyx#24)

@felixfontein I think mellanox.onyx is unmaintained. It looks like the only changes throughout 2022 and 2021 were fixes to sanity tests and similar from @Andersson007, the latest release on Galaxy is 1.0.0 from 2 years ago and there hasn't been a CI run since 4 months.

[felixfontein]

@Andersson007 do you know what the state of mellanox.onyx is? If not, we should start the unmaintained process for it to see whether we can get a reaction.

[Andersson007]

@mariolenz @felixfontein yep, let's start the process, thanks!
if the original maintainers don't respond in the removal issue, we could offer the reporter to become a maintainer.

[mariolenz]

Result of unchanged-dependencies.py 7.0.0 4.0.0:

• cisco.nso [associated vote ended on 2022-12-08] Unmaintained collection: cisco.nso #155
• community.fortios [associated vote ended on 2023-01-16] Unmaintained collection: community.fortios  #162
• community.google [associated vote ended on 2023-01-24] Unmaintained collection: community.google #160
• community.skydive [associated vote ended on 2023-01-24] Unmaintained collection: community.skydive #171
• dellemc.os10 [Vote ended on 2022-10-04] Unmaintained collection: dellemc.os10 #134
• dellemc.os6 [Vote ended on 2022-10-04] Unmaintained collection: dellemc.os6 #132
• dellemc.os9 [Vote ended on 2022-10-04] Unmaintained collection: dellemc.os9 #133
• google.cloud [Vote ended on 2023-02-14] Unmaintained collection: google.cloud #105
• mellanox.onyx [Associated vote ended on 2022-10-11] Unmaintained collection: mellanox.onyx #136
• ngine_io.exoscale

[felixfontein]

IMO community.fortios is similar unmaintained as community.google (some community team members did some generic maintenance work, but otherwise it looks dead - the only interaction with potential users was in ansible-collections/community.fortios#5, and there was actually no interaction so far).

[mariolenz]

@felixfontein I'll have a look at this. And also at community.skydive and ngine_io.exoscale.

[felixfontein]

ngine_io.exoscale is probably still maintained, though CI has been disabled for quite a long time now and the CI matix hasn't been updated for a similar amount of time. CC @resmo who is (or was) maintaining it.

[felixfontein]

The repository for community.skydive is apparently also used for skydive.skydive (https://github.com/ansible-collections/skydive/blob/master/galaxy.yml#L7-L8), which doesn't really exist (https://galaxy.ansible.com/skydive/skydive) - or maybe only on Automation Hub (can't check, I have no access)? Anyway, it seems to be maintained by the ansible network team.

@Qalthos do you know whether the ansible network team still maintains this, and if not, who does / should?

[mariolenz]

Regarding the script: I guess it would make sense to integrate that into antsibull. I'm not sure how exactly though (i.e. whether as a subcomand of antsibull-build, or as a new CLI tool).

If #183 is accepted and merged, maybe we could put it into the scripts/ directory. At least until we find a better solution.

Thoughts?

cc @Andersson007

[mariolenz]

unchanged-dependencies.py 8.1.0 6.0.0:

• cisco.nso Remove cisco.nso from Ansible 9 ansible-build-data#190
• cisco.ucs https://github.com/CiscoDevNet/ansible-ucs/releases/tag/v1.9.0
• community.fortios Remove community.fortios from Ansible 9 ansible-build-data#196
• community.google Remove community.google from Ansible 9 ansible-build-data#198
• community.sap Remove community.sap from Ansible 10 ansible-build-data#266
• community.skydive Remove community.skydive from Ansible 9 ansible-build-data#199
• gluster.gluster Remove gluster.gluster from Ansible 10 ansible-build-data#249
• hpe.nimble Remove hpe.nimble from Ansible 10 ansible-build-data#285
• netapp.aws Remove netapp.aws from Ansible 10 ansible-build-data#243
• netapp.azure Remove netapp.azure from Ansible 10 ansible-build-data#272
• netapp.elementsw Remove netapp.elementsw from Ansible 10 ansible-build-data#276
• netapp.um_info Remove netapp.um_info from Ansible 10 ansible-build-data#280
• ngine_io.exoscale https://github.com/ngine-io/ansible-collection-exoscale/releases/tag/v1.1.0
• servicenow.servicenow Remove deprecated servicenow.servicenow from Ansible 9 ansible-build-data#254

[mariolenz]

I'd like to work on finding (possibly) unmaintained collections once Ansible 9 is released. But is this the right place to keep track?

I mean, just keep this issue and add new lists? Or open a new issue per Ansible release here? Or maybe move it to ansible-build-data? Or wait on the new forum and track things there?

[Andersson007]

we could continue using this issue and move to discourse later when things are fully up and running there

[mariolenz]

unchanged-dependencies.py 9.0.0a3 7.0.0:

• community.azure
• community.network
• community.rabbitmq
• gluster.gluster Remove gluster.gluster from Ansible 10 ansible-build-data#249
• hpe.nimble Remove hpe.nimble from Ansible 10 ansible-build-data#285
• ibm.qradar
• inspur.sm
• netapp.aws Remove netapp.aws from Ansible 10 ansible-build-data#243
• netapp.azure Remove netapp.azure from Ansible 10 ansible-build-data#272
• netapp.elementsw Remove netapp.elementsw from Ansible 10 ansible-build-data#276
• netapp.storagegrid
• netapp.um_info Remove netapp.um_info from Ansible 10 ansible-build-data#280
• splunk.es

[mariolenz]

unchanged-dependencies.py 9.0.0 7.0.0:

• community.azure
• community.rabbitmq
• gluster.gluster Remove gluster.gluster from Ansible 10 ansible-build-data#249
• hpe.nimble Remove hpe.nimble from Ansible 10 ansible-build-data#285
• ibm.qradar
• inspur.sm
• netapp.elementsw Remove netapp.elementsw from Ansible 10 ansible-build-data#276
• netapp.storagegrid
• splunk.es

[mariolenz]

Moving to the forum: Possibly unmaintained collections in Ansible 9