Random things: - I've heard from some that the EC2 metadata service doesn't provide tag data. This seems to be true, which means we can't really make it provide tag data. - I'm open to expanding this module to use additional APIs. - Of the two modules, ec2_facts is rarely used, and dynamic inventory is very widely used - It seems best if ec2_facts conform to inventory, rather than vice versa - 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 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.
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. 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 > <https://groups.google.com/d/msg/ansible-project/ci30yycTbi8/YueCll_vP5oJ> > that it would be nice if the ec2_facts module provided tag data. I > concur. And yes, it's been pointed out > <https://groups.google.com/d/msg/ansible-project/UfDvxM-Rx00/kpKYGX2wkdgJ> > 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: > > 1. Someone writes a play that launches EC2 instances. > 2. 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). > 3. It doesn't work, because this host variable isn't available > in-memory yet after the instance launch play. > 4. Upon a quick googling, they think an ec2_facts play before the DNS > play must be the answer based on what they quickly read. > 5. 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 > <http://stackoverflow.com/q/24389053/455009>, 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 > <https://groups.google.com/d/msgid/ansible-project/9d5e2341-a517-4e18-9a58-f0fb3d29c747%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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%2BnsWgx5bT8N7bFeCfyxWPNVXudZSJnhojcmg8ZW2ODi25%2BzCQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
