On Sun, Mar 9, 2014 at 12:23 PM, Scott Anderson <[email protected]>wrote:
> > On Mar 9, 2014, at 11:59 AM, Michael DeHaan <[email protected]> wrote: > > "Yes, I wrote this precisely because the inventory plugin didn't suit my > needs" > > The problem here is Ansible is trying to serve *everyone's* needs. If it > becomes a conglomeration of 500-ways-to-do-something, we quickly get into a > lot of sprawl. > > > Well, someone highly placed in the Ansible project once told me that the > inventory plugins were just examples, and not really supported... this would > add a supported means of doing this... ;-) > > Things change a lot over time, and my meaning was also different. 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. Thus they don't need to be all things to everyone, either. > While I appreciate your point, the issue remains that the inventory script > (apart from being an "example"), is not a callable piece of functionality. > Having a module able to provide information about instances is highly > valuable by allowing more flexibility. I get the feeling that the only > reason this is objectionable is that it has to do with instances, which are > considered inventory and hence in some way special. This seems to be a > pretty good way to ensure that they are always treated specially, which > will increase the friction any time someone needs to do something slightly > different. > 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. And yes, part of my job is exactly to be the friction or sieve to decide what we take on and what we don't -- so I do need to understand why something couldn't be done with the dynamic inventory data. Are you using ec2.py? What data is missing from what ec2.py returns and what needs to be "callable?" Help me understand more. > > Perhaps the better approach is to refactor both the ec2.py script and this > module to share underpinnings, giving both an external inventory and > internal module view on the same functionality. > I'm still having trouble understanding what "internal module view" here would serve, use case wise. You'll need to convince me, but I can be convinced. I'm just not there yet. > > -- 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/CAEVJ8QOi3SoU7J3AXqkVA%3D8gPnMPfO6CC0bvRr9dH91W6fdoxg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
