Move MySQL modules from community.general to community.mysql

[bmildren]

SUMMARY

I realise it's short notice, but unless anyone has any objections, I'd like to move the MySQL modules (and related content) out of community.general into a dedicated collection community.mysql prior to this Friday's deadline (10th July) so the change can be included in 2.10. Moving the modules into a dedicated collection has many benefits, and also helps reduce the burden on the team supporting community.general.

I'll go ahead and prepare the PR's, but it would be great if members of the working group could reply here to give this a 👍

ISSUE TYPE

• Bug Report

COMPONENT NAME

• mysql_db.py
• mysql_info.py
• mysql_query.py
• mysql_replication.py
• mysql_user.py
• mysql_variables.py

[ansibot]

Files identified in the description:

• lib/ansible/modules/database/mysql/mysql_db.py
• lib/ansible/modules/database/mysql/mysql_info.py
• lib/ansible/modules/database/mysql/mysql_query.py
• lib/ansible/modules/database/mysql/mysql_replication.py
• lib/ansible/modules/database/mysql/mysql_user.py
• lib/ansible/modules/database/mysql/mysql_variables.py

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

[ansibot]

@bmildren: Greetings! Thanks for taking the time to open this issue. In order for the community to handle your issue effectively, we need a bit more information.

Here are the items we could not find in your description:

• ansible version

Please set the description of this issue with an appropriate template from:
https://github.com/ansible/ansible/tree/devel/.github/ISSUE_TEMPLATE

click here for bot help

[bmildren]

@bmalynovytch @Andersson007 @Xyon @Oneiroi @michaelcoburn @tolland @Alexander198961

[Andersson007]

(maybe it should be opened in community.general as in the current place where they live?)

the modules are mostly supported by me now. i personally don't mind if there are moved.
i'm trying to figure out any possible disadvantages of having them not in community.general that are not obvious now...
We have to ask @bmalynovytch as a WG leader, @bmalynovytch what do you think?

@bmildren are you gonning to activelly support the modules there (including CI coverage, bugfixing, doc, etc.:)?
i personally sometimes just forget to look into some small dedicated repos:) so a bit worried they might become abandoned there.
And of course, if the migration happens, i'll be raise a question to apply high quality community.general and community.network standards for them! :)

[Andersson007]

@gundalow @felixfontein ^^^

[felixfontein]

I guess we could set up the same CI as in community.general. That would probably be the easiest solution. Assuming that's ok for @gundalow of course :) @Andersson007 btw when talking about CI, are the MySQL integration tests spread out over different shippable groups, and if yes, is that necessary to avoid conflicts?

[bmildren]

@Andersson007 yep, I've added myself to the working group, and would be happy to contribute to actively supporting these modules.

[bmildren]

@felixfontein for the CI, potentially I can just setup github actions (similarly to community.proxysql), so it might be we don't need to look at shippable for the new collection.

[Andersson007]

@felixfontein i noticed recently that a part of them is disabled, e.g. for mariadb replication. As far as i remember, yes, we use different groups to avoid conflicts between mysql and mariadb dependencies.

@bmildren nice, it actually needs more active contributors. Feel free to text me for reviewing, etc.

[bmildren]

I created some preemptive pr's to migrate mysql out of community.general here:

#70523
ansible-collections/community.general#633

These would obviously only be valid if we go ahead and migrate to community.mysql.

[gundalow]

Sounds like we've got some good people here to help.
Once of the advantages of moving this to community.mysql is we can have every PR run against a set of different MySQL server versions.

+1 from me

[gundalow]

Repo created, if you want commit please shout out.

[Andersson007]

we must not forget to move all related stuff including:

1. module_utils/mysql.py || database.py (the last one is also used, at least, by postgres modules)
2. CI test: test/integration/targets/setup_mysql|mariadb and mysql|mariadb_* roles
3. doc fragments
4. unit tests (if exist)
5. to change M(), examples, seealso, extended_doc_fragments to use a proper FQCN

[bmalynovytch]

Hi there !
I can't think of a good reason not to do so.
Moving the modules should give us more flexibility and less constraints (mostly with other modules in the general section).

👍

[Andersson007]

@bmalynovytch thanks for the reply!

[bmildren]

@Andersson007 - I think I've caught the CI tests/module_utils/doc_fragments (there were no unit tests) in ansible-collections/community.general#633 (anything deleted here will move to community.mysql).

I'll be working today on recreating the CI workflow using GitHub actions 👍

[Andersson007]

nice, don't forget to copy module_utils/database.py (but needs to be rechecked that it's used by the module).
would be cool to run the whole bunch of CI tests after they migrated
and

to change M(), examples, seealso, extended_doc_fragments to use a proper FQCN

(could be implemented later by a separate PR i think)

[bmildren]

👍 I brought module_utils/database.py across yesterday - sanity tests proved some of the modules did 🙂

[gundalow]

YAY FOR TESTS!

I've been starting a checklist for collections: ansible-collections/overview#90 (maybe useful to review) also I'm sure I've missed a lot, so feel free to add comments

[Andersson007]

@gundalow ok! Thanks for the reference

[felixfontein]

Now that the modules have been moved, I guess we can close this issue.