On Sun, Sep 14, 2014 at 12:40 PM, Ches Martin <[email protected]> wrote:
> 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. > > There's a pull request to add an option to standardize the boto facts, that I believe we merged, though I agree it's a little all over the place. Unfortunate result of what upstream is being used - and having a lot of an existing userbase - and not wanting to force a change. I think we need to start considering it though. > 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? > I'd prefer to standardize on what the inventory script does it, since that's more widely used, but to be safe, the easiest thing may be to return *everything*. Though I agree that's also ugly, I'm worried about the upgrade case a little. Maybe too much. Need to think about this some. > 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. > > *nod*. That makes sense to me. Would this be solved short term by just adding "ec2_public_dns_name" as a variable coming out of ec2_facts and ignore some of the other variable issues for a while? (Serious question...) > -- 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%2BnsWgz2-27YqEvx1T36_y15FeUcrYw2x7m%2BXd-kpKrotBbhrQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
