ACP: What to do with purestorage.flashblade and flasharray?

[felixfontein]

@mariolenz

Sounds like you prefer option 3, like me.

Not really. I don’t like any of the three options very much (I mean, I don’t mind if the Ansible package shrinks, but this isn’t really the way its size should be reduced.)

What we could do (but that requires cooperation of the collection maintainers) is:
a) Create new repositories for the “old” collection, that contain their sources and their git tags.
b) Use these repos for the old collections included in Ansible 15, and use the old repos (with the new name) for the new collections which are then also included in Ansible 15.

That way we have proper redirects and the new collections, and due to new repos for the old collections the technical issues for 2 go away.

@mikemorency

As a maintainer of an ACP collection, I feel it is…difficult to both keep up with and know how to do everything that is required for membership. I am fortunate enough to have Mario look over my shoulder and stop me from doing something that might violate the rules. If I was on my own (and certainly if I worked for a company whose primary goal was not to publish and maintain Ansible collections) I think I would have made a few mistakes by now.

I agree, it’s definitely not easy to keep up with all the rules. Maybe we should have a subset of these rules that describe the most important procedural things. IMO these probably are:

1. Stick to semver; in particular: a) backwards compatibility breaking changes only in new major releases, b) new features only in minor or major releases.
2. Make sure your CI is running (and usually passing!) and is testing the latest ansible-core versions (and all others that you claim to support).
3. Have a proper release workflow so that your releases don’t contain files they shouldn’t, and that releases are tagged in the repository. (All collections published through Zuul satisfy this automatically.)
4. If you use or want to add collection dependencies, check out the more detailled rules! In short: only add new dependencies which are already part of ACP, and make sure that lower and upper bounds on versions do not cause problems for ACP.
5. If the Ansible release managers create issues in your repository, don’t ignore them.

I think this covers almost all (or even all) problems we had in the last six years with collections already included in ACP.

@mikemorency

I say that not to argue that the rules should be bent, but rather to suggest that reaching out to the collection/maintainers and telling them what is about to happen would be a nice gesture. The maintainers may even have some ideas on how the issue can be resolved.

This is usually what we do (and often helps to resolves issues). In the case of the two purestorage collections here, this didn’t happen; this is likely my fault. I created PRs to pin the collection versions (flashblade, flasharray) and mentioned the first one of them in the tracker issue. I did mention it in the release manager room on Matrix, though, and looking at the dicussion again right now, I see that something did happen on the forum: Namespace: everpure

In fact, before the rename, when the new namespace everpure was requested @mariolenz explicitly informed the maintainer that there is a procedure for renaming, and that we can help with questions. That happened before the new releases breaking the ACP build were published (which got me to pin the versions). There was never any reply to this message.

Looking at that thread again (I’m surprised that you cannot find the thread on the fourm when explicitly searching for everpure, which I did earlier today and now), it looks like the collections have no interest in staying in ACP.

In any case, pinging @sdodsley, in case there was a misunderstanding / …?