"way to dynamically pass roles".
A good solution here might NOT be to not use ansible-pull. In most cases
most people don't need it if you are doing regular push based configuration.
If you do need it for something like autoscaling - let me recommend an
alternative - ansible-tower provisioning callbacks can run a whole playbook
using "--limit" to run against just the hosts that check in. As such, a
playbook could target multiple groups and just the correct role<->group
mappings would apply.
Ansible-pull is definitely going to continue to be a supported thing since
it exists - but it's not really NEEDED in most cases - and it's not always
the easiest way to get things done, and you lose all that centralized
reporting you get from push mode, or even Tower in callback mode where the
node can phone home and request configuration.
Now, one thing you could do is pass --extra-vars "role=foo"
and do
- hosts: all
roles:
- group_by: key=role_{{rolename}}
- hosts: role_foo
roles:
- foo
- hosts: role_bar
roles:
- bar
And that would do it, with putting the right "--extra-vars" flag on the
crontab entry.
On Fri, Aug 22, 2014 at 3:26 PM, E.C. Raymond <lowl...@gmail.com> wrote:
> I was wondering if there was a best practice for managing ansible-pull
> repos, specifically if there is a way to dynamically pass roles to an
> ansible-pull run. We have an external inventory system that can return
> roles assigned to a host. As in most environments, a host can belong to
> multiple roles, but it seems too messy to create single branches for each
> role to be checked out. I should be able to pull down a master branch with
> all roles intact, and allow the local.yml dictate which roles should be
> applied to the localhost.
>
> # Directory example
> local.yml
> roles
> \-common
> \- tasks,handlers, etc
> |-python
> \- tasks,handlers, etc
> |-database
> \- tasks,handlers, etc
>
>
>
> # local.yml
>
> ---
> - hosts: 127.0.0.1
> connection: local
> sudo: yes
>
> roles:
> - common
> - python
> - database
>
> I previously found that trying to pass a list it to roles via command line
> or in the local.yml, doesnt work as it seems looping isnt supported for the
> roles stanza, only under tasks, and trying to pass --extra-vars from the
> command line to the local.yml file to roles is ignored.
>
> Anyone else doing something similar to this in their environments? We are
> trying to work with a master-less setup, but seems like its more of a
> challenge than using traditional playbooks.
>
> Thanks.
>
> --
> 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 ansible-project+unsubscr...@googlegroups.com.
> To post to this group, send email to ansible-project@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/16ecd8ef-51ac-4bd0-95bb-6fb0e0f29e8f%40googlegroups.com
> <https://groups.google.com/d/msgid/ansible-project/16ecd8ef-51ac-4bd0-95bb-6fb0e0f29e8f%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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgzUrnoXX57Gt%3DdibFMx%3DC1-p77T4c3MJCm8Z61hvxrQsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
