Certification of community.mysql collection on Automation Hub

Project Discussions
, , ,
1

Hello everyone,

We are thinking of certifying community.mysql which will result in its availability on Automation Hub.
What the certification will bring to the community:

  • Some additional testing and manual checks that will ensure the collection will run on Ansible Automation Platform: even if most of users don’t run it there it’s addition testing which is always good, isn’t it?
  • Red Hat allocates time of Ansible content team to ensure everything is well tested which will result in better coverage, additional checks, etc. Red Hat’s testing approach is understandably very thorough and good IMO.
  • If there are critical bugs or security vulnerabilities, Red Hat will allocate resources to fix them ASAP
  • The collection must be renamed to ansible.mysql or there must be a fork serving as downstream
  • IMPORTANT: the community maintainers will keep their permissions in the projects whether it’s renamed or if community.mysql stay as upstream.
  • So I personally don’t see any downsides here. A couple of examples of certified collections: vmware.vmware, ansible.windows, ansible.posix

I see two options here:

Option 1: Two collections exist: community.mysql (upstream), ansible.mysql (downstream)

  • We fork ansible.mysql (will be downstream) from community.mysql (will be upstream).
  • In ansible.mysql,
    • We’ll put it clear in README and contributor docs that contributors / users should go to community.mysql to open issues/PRs.
    • We’ll backport stuff from community.mysql and release periodically with some delay (we’ll develop
  • We certify and release ansbile.mysql on AH.
  • If maintenance upstream → downstream get burdensome, we’ll deprecate community.mysql and move the development fully to ansible.mysql (it’ll work same as in ansbile.windows, ansible.posix, so there’ll be no upstream-downstream).

Pros of this approach:

  • No need to replace community.mysql with ansible.mysql in the Ansible community package immediately by adding all those redirects and deprecations
  • ansible.mysql is more stable as it’ll be released with some delay

Cons:

  • Potential maintenance burden (tracking 2 collections, backporting stuff)
  • Potential split brain; potential merge conflicts later

Option 2: Rename community.mysql to ansible.mysql: it’s known process already done in collections many times)

  • We fork ansible.mysql from community.mysql
  • We put deprecations and redirects in community.mysql to refer users to run ansible.mysql instead. The work will continue in ansible.mysql. No changes to community.mysql since then. Users who run community.mysql will actually run ansible.mysql transperantly.
  • Then, in 1 year or so (after two major ansible package releases), community.mysql will be removed from the Ansible community package and possibly archived. The work will continue in ansible.mysql.

What do anybody think? Would be great to hear opinions of our community mainteiners @laurent-indermuehle @betanummeric and @markuman

1 Like
2

I guess there’s also option 3, which some collections use: the repo is for both collections, if you clone it you get community.mysql, and there is some rename tooling that produces ansible.mysql out of it. This is more comparable to option 1, I guess, since it’s also a PITA :slight_smile: (I just wanted to list it for completeness.)

Renaming is probably the easiest. Though there are also other options on how to rename it: you could rename the whole repository instead of forking, and then fork it back to the old name. That way all issues are kept with the new repo, and there’s less breakage for everything already happening in the repo. (Like issue and PR numbers keep working - URLs obviously do not, but ones in the current repo can be changed.)

It would be even better if there wouldn’t be a need to fork to the old collection name, and simply release the old collection from some branches, but I don’t think Zuul can handle that. (That would also drastically simplify backports, since they happen in the same repository, so you can simply use the patchback bot.)

2 Likes
3

Hi all,
I would prefer to keep it a single repo and avoid confusion like

  • Which flavour should I use a user?
  • Where should I submit issues and PRs?
  • Which bug is patched in which version of which flavour?

Will ownership of the repo change with option 1? Will Red Hat get maintainer privileges on the repo?

2 Likes
4

@felixfontein cool, thanks for the input and the additional options!

1 Like
5

Hi @betanummeric ,

  1. Will ownership of the repo change with option 1?, no, you’ll keep commmit as well as other active maintainers
  2. Will Red Hat get maintainer privileges on the repo?, yes, but it has it now because the repo is under the ansible-collections org
1 Like
6

ok, then I would prefer option 2

1 Like
7

I don’t see downsides either. Great news for the collection that Red Hat acknowledges its value and popularity. :slight_smile:

I dislike the idea of changing the collection name. Having to change the FQCN in every playbook out there would be painful for our users.

Why if community.mysql == ansible.mysql, couldn’t the certified collection just be a git tag or commit hash that Red Hat chose?

1 Like
8

@laurent-indermuehle , good question - the name must change to ansible.mysql.

UPDATE: there’ll be plenty of time to run sed oldname/newname.

9

@felixfontein do i understand this approach correctly that:

  1. We rename the repo in place to ansible.mysql
  2. We fork community.mysql back out of it
  3. In ansible.mysql: We change community.mysql → ansible.mysql in docs, comments, URLs, and everywhere.
  4. In ansible.mysql: We release it on Galaxy.
  5. In community.mysql: We add deprecations/redirects to the new one as we usually do when renaming collections that are part of the ansible community package.
  6. In community.mysql: we release it, mark as read-only, etc.
  7. The development continue in ansible.mysql

Do you think my chain of thoughts is correct?

1 Like