This is something I've thought about too. The variable naming mismatch has caused me some headaches as well as the issue of trying to load all of the information that the EC2 dynamic inventory pulls for newly provisioned machines. Would be nice if I could add_host and ec2_facts without having to worry about what the vars are called.
But renaming the variables in either one would cause problems for existing playbooks, so it would need to keep the old names around for existing uses. This could lead to some confusion as the hostvars will be polluted with duplicate entries and there's no real way to encourage people to use the "right" names for the vars. IMO the ec2.py script should be changed to match the ec2_facts module as the latter is an official part of ansible and the former is often referred to as a "starting point" for your own inventory scripts. On Sat, Sep 13, 2014 at 5:28 AM, Ches Martin <c...@nausicaamedia.com> wrote: > Hi folks, > > I dug around the list to see if anyone has raised this point before and > didn't find it addressed directly, excuse me if I missed something. > > Michael has stated before that it would be nice if the ec2_facts module > provided tag data. I concur. And yes, it's been pointed out that the EC2 > inventory plugin provides tags as hostvars—along with other facts—which is > very useful, most of the time more convenient than using the ec2_tag module > when you just want to fetch a value. > > I am reaching an itching point with the disconnect between these two sources > of EC2 facts, though. They're both officially supported but it feels obvious > that they originated from different contributions. There is redundant data > under different variable names. Different semantics for what might/can be > in-memory. My team gets confused about what vars are coming from which > source, and when they should use one versus the other. Searching the mailing > list seems to suggest that it confuses others too. > > Usually we prefer info from the inventory plugin when possible (primarily > because of the readily available tags, as aforementioned), but it falls > apart for provisioning plays, for instance: > > Someone writes a play that launches EC2 instances. > They add a follow-up play that creates DNS records for the instances, using > ec2_public_dns_name (a variable from the inventory plugin, which they've > become accustomed to using). > It doesn't work, because this host variable isn't available in-memory yet > after the instance launch play. > Upon a quick googling, they think an ec2_facts play before the DNS play must > be the answer based on what they quickly read. > It isn't. ansible_ec2_public_hostname is the answer, and that ec2_facts > play. > > This sounds like a lot of incidental complexity to me. > > And there's still the matter of tags. Getting tag data into memory for > instances launched in the same run proves to be pretty ugly/cumbersome, > currently. Wouldn't it be nice if all you needed was the ec2_facts refresh > play to load new tags? > > So what can we do about this? Ideally, I'd like to use the EC2 inventory > plugin, and have ec2_facts work to refresh values of the same host var keys > in-memory. Inherent in that is that I'd like to have consistent variable > names throughout my code base. Of course some people may want to > occasionally use ec2_facts without using the inventory plugin (I guess?). > That should be fine, but they could work together seamlessly. > > I'm willing to take a stab at working on this, but wanted to bring up > whether it would be welcomed, what major concerns there may be, etc. > > Thanks for reading. > > -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/9d5e2341-a517-4e18-9a58-f0fb3d29c747%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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/CAJQqANdqu7TkyX3Vwsu7fND36r9djjHmvGa1r690yu6CP8sJUw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
