# New Adopter, Some Thoughts **URL:** \ **Category:** Ansible Project\ **Created:** [June 27, 2013, 9:25pm UTC](https://forum.ansible.com/t/new-adopter-some-thoughts/13030 "2013-06-27T21:25:04Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Kevin\_Montuori](https://avatars.discourse-cdn.com/v4/letter/k/bbce88/32.png) [@Kevin\_Montuori](https://forum.ansible.com/u/Kevin_Montuori)\ **Post date:** [June 27, 2013, 9:25pm UTC](https://forum.ansible.com/t/new-adopter-some-thoughts/13030/1 "2013-06-27T21:25:04Z")
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. ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [June 27, 2013, 10:44pm UTC](https://forum.ansible.com/t/new-adopter-some-thoughts/13030/2 "2013-06-27T22:44:28Z")
Hi Kevin, Thanks for some really good feedback, I’ve replied inline.