> > > 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. >
No, it should not. ec2.py is much more widely used, and both are parts of Ansible. We don't ship inventory scripts in the distro - but we probably should. They are most definitely more widely utilized than the facts module. > > > On Sat, Sep 13, 2014 at 5:28 AM, Ches Martin <[email protected]> > 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 [email protected]. > > To post to this group, send email to [email protected]. > > 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 [email protected]. > To post to this group, send email to [email protected]. > 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. > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgwc9pP6hUwyXAbuyo8ghqVidoEH%2BfEpzfSwXpWKpMCtMQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
