In this PR, there is talk of magic modules being used to generate ansible modules for GCE. Is this a general decision that means no more contributed modules will be accepted if they are already generated by magic modules?
I do not see any indication in that PR that states that it is being denied. From looking at that module it has been approved by one of the committers.
We have discussed that we won’t treat these modules any different than another module. The plan is basically that we would ignore how they were created and where they came from. If a user submits a PR, and the maintainers of that module do not handle it in a way that it is resolved, there is the potential that the PR is directly accepted, causing the module to diverge from the auto generation.
This will just be a caveat and something that needs understood by those who have contributed the module generated module.
The module will also still be required to pass our tests and guidelines for any other module.
All of what Matt mentions is true - additionally:
One of the reasons driving MagicModules is that the GCP SDK used in many Ansible modules is very inconsistent: some modules require libcloud, others require googlecloud-python, and others require another, older SDK. To avoid changing the deps of existing modules (like gce_eip) we’re reviewing newer versions of similar functionality from MagicModules. That doesn’t mean that all modules will be MagicModules, nor does it mean we’ll stop taking community PRs on the generated modules, for new modules, or for existing modules.
Hope that clears things up,
Ryan
We normally caution against autogeneration for a few reasons:
- Any time someone else contributes to the module, it breaks the next
autogenerated update, you need to create a process to syncronize
contributions in.
- Options normally are made as passthroughs to the API, this tends to
create modules that are not very user friendly, closer to programming
functions than a declarative state
- Error messaging is mostly the same as the API's, which is fine for
programmers, but not most users
- The documentation quality tends to suffer, mostly just reflects the
API docs, again sufficient for most programmers but not for other
users
- Issues get filed against the generated code, not the generator, this
can create a lot of work as it is 'complex double bookeeping'. Which
goes contrary to the main reason to autogenerate the modules, to
minimize the developer workload.