I recommend you take a step back and look at the problem from the
perspective of your overall Configuration Management (CM) process. For
example, what are your configuration items (CIs)? What is your change
management process? What is your version control process? First document
these process
David,
I'm coming from a similar place in terms of seeing things as roles with
features and I'm also just getting started with ansible.
I made a common role considering it as 'included for all roles and applied
conditionally'.
Tasks are included based on group membership, or host in inventory
It's cleaner to have the roles explicitly listed up in site.yml .
Then site.yml defines the roles on each host group, and you avoid the
issue with roles running twice when you explicitly define them that way.
You can still have 'states' as you define them just as typical roles, maybe
with a README
Hi Michael and others,
It could be me explaining wrong, or I could be off the path, but let
me try again. My site playbook is basically only used to tie roles to
host groups. Those roles are specific for our infrastructure, e.g.
setting up our frontend server, backend server, etc. I call those
"pr
>
>
> Both profiles and states are roles, but I separate them into two roles
> directories. I then use role dependencies between profiles and states (and
> states and states). A playbook simply ties hosts to profile roles.
>
> A few thing I ran into:
> * I needed to use a trick to make sure each st
On Tue, Jun 3, 2014 at 1:37 AM, wrote:
> Yes. I'm only new to ansible but am seriously struggling. The playbooks I
> can get my head around but the roles are proving very painful. I thought
> the idea might be to switch features on/off for each host via variables?
> Would that work?
>
I sugges
On Monday, June 2, 2014 9:38:45 PM UTC-7, David Carmean wrote:
>
>
> In my mind, any particular role that a server may fill (and it may fill
> more than one), in turn requires one or more "features" or "feature-sets"
> in order to be able to fulfill that role. In other words, I think of a
> h
until you find a
layout that works best for you.
Thx
Gopher.
From: ansible-project@googlegroups.com
[mailto:ansible-project@googlegroups.com] On Behalf Of Brian Coca
Sent: Tuesday, June 03, 2014 8:25 AM
To: ansible-project@googlegroups.com
Subject: Re: [ansible-project] Re: Are Roles enough
roles are there to make reusable units of non trivial set of tasks,
sometimes its just easier to create a simple tasklist and use include:.
If it is becoming 'painful' its a sign of trying to put square peg in round
hole. Ansible is designed to be simple, also it is very flexible and can be
used i
Recently I have changed my Ansible set-up based on roles. I have a very
similar dependency structure as yours:
host1 -> profile1, profile2
host2 -> profile2, profile3
profile1 -> state1, state2
profile2 -> state2, state3
...
Both profiles and states are roles, but I separate them into two roles
Yes. I'm only new to ansible but am seriously struggling. The playbooks I
can get my head around but the roles are proving very painful. I thought
the idea might be to switch features on/off for each host via variables?
Would that work?
[Trivial annoyance: i hate the way it requires a bunch o
11 matches
Mail list logo
