Hi All --
I've been leveraging Ansible for a few weeks now to provision and
configure ephemeral "demo" and "development" instances on EC2, to the
great delight of the dev and product management teams I support. My
hearty thanks to everyone who's contributed, it's a very usable product
and doesn't suffer from some of the pitfalls of other configuration
management solutions.
I have a few comments that I don't want construed as complaints: it's
entirely possible that I'm either not fully tuned in to the Ansible Way
or maybe I haven't read the correct sentence in the documentation yet.
* I don't always know in advance what playbooks I want to run on what
hosts and once I've figured that out I don't always have an
appropriate inventory file available (my instances are ephemeral and
often multi-use). To support that:
- I'd like to be able to feed ansible-playbook a host pattern, just
like ansible; and,
- I'd like to be able to specify a hostname (and no inventory file at
all) on the ansible-playbook and ansible command lines.
Are there any efforts underway to provide this functionality? If not,
are there strong objections to allowing it if I were to submit a pull
request implementing it?
* The S3 module is presumably useful in some cases but missing half of
the functionality I'd expect: specifically, I'd like to provide a
bucket/path and a filesystem destination and have the file specified
downloaded to the destination. Would you see this as a separate
module entirely (I've implemented a rough version as S3slurp) or is it
more appropriate to augment the existing S3 module?
* There are times I'd like my dev staff to be able to "lock out" Ansible
updates in a way that I, the Ansible driver, don't have to know
about. I have a little module to do this (I've dubbed it "lockcheck")
that looks roughly like:
pre_tasks:
- name: check for lockfile
action: lockcheck lockfile=/var/tmp/no.provision
....
lockfile = module.params.get('lockfile')
if os.path.exists(lockfile):
module.fail_json(msg="lockfile %s exists" % lockfile)
else:
module.exit_json(changed=False)
so that the dev can simply touch or rm a file and have the right thing
happen (where "right thing" in this instance is an early playbook
failure on the host). Any interest in this as part of the standard
library; if so, suggestions for an appropriate name?
* I'd very much like to have a "when" variant that executes a command
(just like the command module does) on the target host and uses the
exit code to determine if the action should be taken or not. This is
achievable with two steps (execute the command and capture the result,
use the result in the next play) but then I have plays that are only
being used for their side effects. Am I alone in missing this
functionality (or, perhaps, not understanding the full range of tests
that "when" can perform)?
* Has any thought gone into allowing some parts of a playbook to be run
in parallel? My use case is pretty simple: I have a half dozen
products that need to be released when provisioning a demo host that
could be executed simultaneously. The only benefit in this case is
faster execution (it would take about 1/6 the time) but given the
circumstances in which a demo host is being provisioned, an extra
minute or two matters (some).
* And a couple of documentation/website comments:
- the Technology -> Downloads page doesn't actually have a link to
either a downloadable package or to the source;
- a reference guide to the directives that comprise a playbook would
be hugely helpful -- there's pretty good documentation once you know
about the directive but sometimes knowing that it exists is most of
the battle;
- the "Module Development" page essentially says RTFS and never
completes the "time" module with the standard module boilerplate
... examples are great but an API doc would be more helpful;
- I didn't see mentioned anywhere that home grown modules have to be
used in playbooks as:
action: module name=quux
instead of
module: name=quux
clarification on that point might save the next guy some time.
Thanks again for a useful product. I'm looking forward to seeing how it
develops.
k.