Thanks Michael, that's helpful, especially about giving favor to the inventory plugin. I'll try to drop in IRC when I can start hacking on it (probably a week from now), I'm sure I'll have some questions about internals like what you're saying about module_utils, but a few remarks:
On Sunday, September 14, 2014 8:35:16 PM UTC+7, Michael DeHaan wrote: > > > - It seems best if ec2_facts conform to inventory, rather than vice versa > > It might be useful to call out specific examples other than just the tags > being missing, such as which variable names you don't see standardized. > Well... basically all of them: ec2_facts uses ansible_ec2_ as a prefix, the inventory plugin uses ec2_. It's not only prefix, the public hostname thing is an example, which I'll get to in a sec. When I'm sitting at a working environment I'll gist some censored output from ec2.py --list and ansible -m ec2_facts for sake of reference in discussion. The inventory plugin has this comment FWIW: These variables are pulled out of a boto.ec2.instance object. There is a > lack of > consistency with variable spellings (camelCase and underscores) since this > just loops through all variables the object exposes. It is preferred to > use the > ones with underscores when multiple exist. Setting aside the issue of which names are kept and backwards compat for now (I think it's pretty clear that we'll want to preserve it, for awhile at least), would you prefer to standardize on ansible_ec2_ as var prefix? - We don't want to break anyone, but this may be unavoidable. As such, I'd > suggest a return_mode='v1', defaulting to something like 'v2', and making > sure common code from module_utils is used so that functions from the > inventory script return the same data > I assume the return_mode refers to a new option for the facts module, that sounds reasonable. What do you think about the inventory plugin? I actually hadn't realized they weren't in the distro until you just pointed it out. I have seen, like, one blog post where someone shows an example that git clones ansible, uses the hacking setup, and symlinks ec2.py into their playbooks repo. I tend to think/hope few people do that in "real life". I have vendored a copy of the script in our repo, so upgrading Ansible wouldn't break me unexpectedly, but that's just me. - I don't understand some statements in the above, like I can't parse " > ansible_ec2_public_hostname is the answer, *and* that ec2_facts play." > what that means. Sorry, my anecdote was a little contrived, because the use case of "launch new instances and then create DNS records with their public names" can be solved just by using a register on the launch play, the necessary info is available in the result and ec2_facts isn't needed. The point I was trying to make is that the inventory plugin calls it ec2_public_dns_name and there's no convenient way to get that specific var name associated with newly launched hosts in memory during the run (okay, you could do it manually with add_host and the values from registered ec2_result.instances, but I said "convenient"). Imagine a more complex case where you add_host new instances to an already-existing group, and do more with the group later in the run. So you loop over the group and try to do hostvars[host].ec2_public_dns_name. This will break on the newly launched hosts. What will work is to run ec2_facts for the group, and then use hostvars[host].ansible_ec2_public_hostname. I hope that makes sense now. My team favors the inventory plugin most of the time but cases like this trip them up. Particularly because we use tags a good deal, we've become conditioned to first looking to ec2.py --list to find EC2 vars to use, hence there's a bunch of ec2_public_dns_name and its ilk used throughout our playbooks. People are confused when they write a provisioning playbook and these fail. I've had to explain this discrepancy multiple times. -Ches -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/390e0d6e-eb54-4dd7-82e0-a11e09ff0a29%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
