Some questions about moving from community.general to own collection

[SHxKM]

My company currently has a single module hosted under community.general, and a completely disconnected* Github repository with this module, plus three others. We have already made the decision to move to a collection under our own namespace, and deprecate (according to Ansible standards) the community.general module.

I'm wondering about the following:

• The current module's name in community.general is something along the lines of community.general.cloud.prefix_module_name.

• In the new collection, we'd prefer to have it as some_comp.collection_name.module_name; i.e.: without the prefix that currently exists for the module in community.general.

My question is: is this kind of change going to prevent/hamper the deprecation/migration process? As I understand, current consumers of either community.general.cloud.prefix_module_name or the directly installed modules will have to modify their ansible playbooks anyway? so we might as well use the shorter naming convention. But I want to verify this is not going to prevent us from eventually deprecating the module in community.general.

* Disconnected - not synced with community.general nor published to Galaxy, consumers usually install by cloning.

[felixfontein]

The current module's name in community.general is something along the lines of community.general.cloud.prefix_module_name.

It is community.general.cloud.prefix_module_name and not community.general.prefix_module_name.

My question is: is this kind of change going to prevent/hamper the deprecation/migration process?

No. See for example the routeros modules moved from community.network to community.routeros; they were called routeros_* before the move, and * after the move.

[felixfontein]

Yes. We will only add redirects if existing usages of the module will result in exactly the same behavior with the new module.

[SHxKM]

Yes. We will only add redirects if existing usages of the module will result in exactly the same behavior with the new module.

Hmm, then we have an interesting question here: our current module in community.general has a dependency (our own library) which we no longer maintain. It is also very very outdated. The same module in our new collection will have a breaking-change dependency. I understand now that it would be impossible to redirect, but can we request the removal of the module? (assuming we prove "ownership")

[tadeboro]

I think we can still get away with redirects here if we introduce them at the start of the new major version of community.general.

For example, let us assume that community.general version X contains module foo that depends on libfoo package and that replacement module lives in my_ns.my_col under the name bar that has a dependency on libbar package. If the bar's public API is compatible with foo's (in a sense that running the same playbook using different modules produces the same result), then placing redirect for community.general X+1 should be safe and we can also add information about changed deps to migration docs when the redirect is installed.

If modules are not compatible, then the best way is to deprecate and eventually remote foo and instruct users to manually migrate to bar.

Installing redirect means that your collection will need to be part of the ansible package. If we take the deprecate-and-remove route, you can probably get away with not being part of the ansible package, but I would still suggest you apply for inclusion.

[SHxKM]

First off again thank you @tadeboro and @felixfontein it’s amazing the level of support here.

Our goal is definitely getting included in ansible in the long term. However, we have much to do in terms of sanity-tests (especially documentation) so as a first step we want to publish to the galaxy and gradually get the collection to meet the requirements.

So yeah I think our goal anyway is deprecate the one in community.general in the long term (even though it’s not necessary).

[tadeboro]

Getting your collections published and stabilized (releasing version 1.0.0) is the first step in the whole process. Once you have this ready, we can start thinking about the follow-up steps. And as I said, if you manage to keep the module behavior/API the same as the old module, I see no major issues installing redirect even if dependencies change. If not, then deprecating and removing is probably the way to go since maintaining two copies of the same thing, in the long run, makes no sense.