Just trying to understand: what is your proposed solution for, say 'starting all EC2 VMs that match tag_env_prod in zone US-WEST-1'?
| Technically you can, however, use an inventory script and static data at the same time, as long as they are all in a common directory. PS.: BTW, I tried using multiple inventory files but it didn't work with ansible.cfg, only with the -i param. On Sunday, March 9, 2014 4:12:25 PM UTC-7, Michael DeHaan wrote: > > > > > On Sun, Mar 9, 2014 at 5:28 PM, Scott Anderson > <[email protected]<javascript:> > > wrote: > >> >> On Mar 9, 2014, at 12:35 PM, Michael DeHaan >> <[email protected]<javascript:>> >> wrote: >> >> > In particular, if there are non-standard use cases, they are things >> that can be adapted and modified. There are already a ton of people >> contributing to all of the inventory scripts. >> > >> > Still, they are in fact examples -- meaning people are also free to >> modify them if they want to add more groups and so on. >> >> From the viewpoint of a CTO, I'm not interested in using and modifying an >> example if there is a way to get the same functionality in a supported >> fashion. As soon as I modify something like that for my own purposes, I'm >> walking down a path that leads to just doing it myself. It's not a great >> place to be from a maintenance standpoint. I use tools like Ansible to >> avoid precisely that situation. I'm happy to contribute, but only if by >> doing so I can get code into a community-maintained and supported path. >> > > Not understanding the titles part of the thing. > > Just seeing a hypothetical playbook example would help me understand quite > a lot, where right now I have gaps in understanding. > > >> >> > I'd need to better understand use cases to see why this didn't fit. It >> seems one of the best place to put data-driven information about existing >> instances. >> > >> > I'm also not sure what you mean about "increasing friction here" -- >> they are in fact inventory, so this is more of a discussion about not >> duplicating things that can be easily sourced from inventory. >> >> One of my points is that everything else other than inventory is handled >> via modules; for inventory you're saying "here, do this another unsupported >> way with this example script". Inventory is somehow "special", and as a >> result it's not treated similarly to other resources in the infrastructure >> (such as RDS instances, ElastiCache instances, etc). Because it has an IP >> address and it's something that can be logged into, it's now handled via a >> completely different pathway. >> > > There are two types of things. > > There are things that are done and need to be, and then there are things > that are -- sources of truth and existence. Inventory scripts are very > much like input, they don't express state, but they relate a ton of > information about what you have running. > > >> >> I can already use add_host to perform playbook-internal additions to >> inventory. But there's no way within a playbook to query facts about >> existing instances: that has to be done at the start of the playbook with >> an external script, or by logging into every individual instance and using >> ec2_facts. >> > > I'm still curious why the inventory script can't just return this data. > > A playbook or deeper use case example would help me understand more. > > >> >> Most of my play books are doing things via AWS and boto-related modules, >> not on hosts that are being accessed directly. I just want to be able to >> treat instances the same way as other resources from a consistency >> standpoint. >> >> > Are you using ec2.py? >> >> I have used it, yes. Given that I'm moving my infrastructure to an >> AMI-based stem cell approach, however, ec2 inventory doesn't really mean >> much any longer. Every instance is ephemeral and the only thing I really >> need to manage directly in AWS (apart from other AWS services) is a >> maintenance instance that is used to create an AMI. >> > > If doing AMI builds, I think the need to interrogate the instance would > actually be *reduced* for most people, as you'd just let the ASG take over. > > > > >> Another major miss, however, is this: I need to update a set of machines >> not in ec2 with information about ec2 instances. So, my inventory file is >> going to be something other than ec2.py, but I want to automatically gather >> information about the relevant ec2 instances and do things to the local >> inventory with the results. I think this example most clearly demonstrates >> why constraining gathering inventory information to an actual inventory >> script is inconsistent with treating instances like other resources. >> > > > Technically you can, however, use an inventory script and static data at > the same time, as long as they are all in a common directory. > > > -- 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/511518b9-142c-4f52-ba54-bb56ccbc66b8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
