On Sun, Mar 9, 2014 at 5:28 PM, Scott Anderson <[email protected]>wrote:
> > On Mar 9, 2014, at 12:35 PM, Michael DeHaan <[email protected]> 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/CAEVJ8QOSO7cWeimqc86148qqfGcShwjp9URg4Y5J5MAMx5VJOg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
