Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ansible-module-init script #49

Open
jctanner opened this issue Jan 26, 2017 · 5 comments
Open

ansible-module-init script #49

jctanner opened this issue Jan 26, 2017 · 5 comments

Comments

@jctanner
Copy link

jctanner commented Jan 26, 2017

Proposal:

Author: James Tanner @jctanner IRC: jtanner

Date: 2017/01/26

  • Status: New
  • Proposal type: new script
  • Targeted Release: future ...
  • Associated PR: N/A
  • Estimated time to implement: 1 week

Motivation

Developers will typically copy an existing module or read through the dev guids to piece together their first module. I want to make it easier and more approachable to get a basic noop module created, via a simple script.

Problems

What problems exist that this proposal will solve?

  • Less reliance on written prose
  • Old modules may not be what we want people to copy for new modules
  • New devs might find module development difficult to start on.
  • Linux devs might not have a clue where to start on windows modules, but this could narrow the gap.

Solution proposal

$ ansible-module init foobar
 .. creating libary/foobar.py
$ ansible localhost -m foobar

Dependencies (optional)

Testing (optional)

Documentation (optional)

Anything else?

@gundalow
Copy link
Contributor

I love this

Some initial thoughts

  • Docs need to come first

Different classes of modules

  • Linux (.py
  • Windows (.py and .ps1)

Extends (future)
Knowing if the module extends ec2, etc would allow us to put in boiler plate stuff for

  • extends_docs_fragment
  • BOTO check
  • argument_spec = ec2_argument_spec

@dagwieers
Copy link
Contributor

dagwieers commented Jan 26, 2017

I would rather pick a (real) reference module for each class of examples (e.g. Unix, Windows, network, ...) and then make sure that module is the first one that gets update/documented if new ways of working are implemented. That is what I intended with ansible/ansible#20509

The reason for this is that it's easier to see what a best practice is from real examples. Selecting a good reference module is not that easy as the module should not be too complex, but have all the different variants to parameter types, check-mode, diff-mode, warnings, etc.

But I prefer real modules over some sort of template, which often go stale or are an afterthought.

So maybe yet another ansible command is overkill (and harder for users IMO).

@gundalow
Copy link
Contributor

@dagwieers I agree.
I like the idea of ansible/ansible#20509 for Windows. We (Testing Working Group) had previously agreed to use https://github.com/ansible/ansible-modules-extras/blob/devel/cloud/amazon/kinesis_stream.py for Linux
See Line 209 https://public.etherpad-mozilla.org/p/ansible-testing-working-group Though it needs some updates.

Better docs to follow soon :)

@webknjaz
Copy link
Member

webknjaz commented Nov 9, 2018

Remark: this is probably achievable using cookiecutter, which would also allow having customizable templates...

@bcoca
Copy link
Member

bcoca commented Nov 30, 2021

should this be moved to 'devtools' now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants