The past weeks I’ve been working on a module which might be added to the Ansible ‘extra’ modules. I found the process a bit frustrating on some points, so I thought I’d share that here. I hope you don’t mind
The first obstacle I found was that the modules are actually in a separate repo, but the accompanying tests are not. This requires two pull-requests that are semantically connected, but technically separate.
Once accepted, the module would live in the ansible-modules-extra, which makes it harder to keep track of possible bugs/features/pullrequests. I understand that once merged it should be maintained (or at least maintainable) by the Ansible crew - but as a module author I’d be more than happy to chip in.
Finally, writing a module in a modules-extra way means that it’s a single self-contained file that generates docs. These docs are ok, but formatting them is a bit of a PITA since it’s in yaml and not restructuredtext or even markdown.
Seperate module repos actually helps us with ticket prioritization a lot.
As for tests in different repos, we may have an option for that in the future. However, right now, other priorities indicate this is unlikely to be changed near term.
As for not liking that docs are YAML, they are YAML because they are data, they are not intended to contain formatting. The EXAMPLES block is free-form text however.
I believe all the moves on Ansible’s part including separate repos are the right ones, I’m not arguing those. I’m also not bothered by the docs of the core/extra modules, it’s just the way it is - and the self-containedness of the modules is a huge plus.
But there’s always going to be modules that don’t fit, or are too new and unproven to be included in core or extra. My suggestion was that the galaxy path be advocated or endorsed by Ansible, for reasons already stated. Anyway, I was just floating an idea.
Thanks for taking the time to respond, you’re a machine!
Perhaps it’s time for a ‘bleeding-edge’ branch, particularly of extras. Allow more community control of that branch at least, and encourage experimentation.
If you use those modules, it’s at your own risk, but it’s a way to test and experiment prior to inclusion in devel (by which time you’d expect stability, backward compatibility etc) and then perhaps inclusion in core.
