You should not patch ansible as you'll drift from mainline pretty steadily
and the bugs you file will be invalid.
an easier solution here would be to either:
(A) just generate the playbooks mapping groups to hosts
(B) use conditionals for the hosts like an "apps" array, and do the
following to avoid
- hosts: all
tasks:
- group_by: key=webservers_{{ 'webserver' in installed_apps }}
- group_by: key=dbbservers_{{ 'dbbserver' in installed_apps }}
- hosts: webservers_True
roles:
- webserver
- hosts: dbservers_True
roles:
- dbserver
(C) Ultimately, it's easier if you just have a static playbook and just
return the hosts that should be in each role based group.
On Fri, Apr 18, 2014 at 7:54 PM, larry tjoelker <[email protected]> wrote:
> I have a couple of probably simple questions about using Ansible properly.
>
> Background: Its not practical in our environment to install every software
> stack component needed by individual applications on all relevant hosts,
> so, rather than classify our hosts according to their detailed software
> profiles, we remember the bits necessary to support each application in a
> database. I.e. we have an application-centric inventory.
>
> These specialized software components are installed by ansible over our
> standard stacks and maintained in ansible roles. Ansible role names, as
> read from the standard ansible directory structure, are attributes of apps
> in the inventory database
>
> At the cost of tying our ansible directory structure to the inventory,
> this allows us to keep track of provisioned bits and, as well, more fully
> and automatically configure application specific bits during provisioning,
> For example, create Apache's vhost config files from templates with all
> app-specific details gleaned from the database.
>
> Problem: The list of ROLES that accomplish app provisioning comes from the
> database (by an inv.py script like the one blogged by Jan-Piet Mens) via
> the ansible environment and courtesy of THIS PATCH to ansible's play.py:
>
> 66, 72
> #self.roles = ds.get('roles',
> None)
> try:
> self.roles =
> (self.playbook.inventory.get_group_variables(os.environ['APPGRP']))['roles']
> except:
> self.roles = ds.get('roles', None)
>
> (The try / except clause is used in the hope that our change is
> transparent, but that has not been tested.)
>
> I suspect that this change breaks Ansible's intended model, or else it
> would not have been necessary. It appears that the modded code is in a
> pretty stable part of ansible, or at least I hope it is. Does anyone have
> any dire warnings or other advice? Is this a serious breakage?
>
> thanks,
> larry
>
> --
> 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/e0f84da1-7ffe-492a-9192-6e473a784491%40googlegroups.com<https://groups.google.com/d/msgid/ansible-project/e0f84da1-7ffe-492a-9192-6e473a784491%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%2BnsWgybtErH8At%3DDuG5FfRwFXwPBTehJSYAd8qqjXtXFb20LQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
