Thanks for the suggestions how to solve this problem.
Maciej's solution is great, since you don't have to modify a role nor
create a new one, you just pass different variables and you are good to go,
but the problem I have with that solution is that it makes it harder to
read what you configured and sometimes even harder to know how will the
resulting configuration file look like until you execute the playbook. It's
much easier to read and edit a well documented configuration files, than to
read/write variables in YAML. This also makes it easier to make a mistake.
If you have a lot of variables configured in a template, it makes it much
easier to mistype a variable, or something similar, so it doesn't generate
good configuration file. I checked what you did with the php-fpm role and
it's really good and easy to read, but the nginx one isn't that readable
and it feels too complex.
I'm not a fan Ernest0x's/Dave's solution of having a *-common role which I
set as a dependency for a new role, since that would mean I would need to
create a new role for each new server. The main reason I'm don't like this
approach is because that makes an even bigger overhead than what I'm
currently doing (adding new configuration files to a role), since you need
to create a whole new role, but also it configures the e.g. nginx via more
roles, which I would like to avoid. Role nginx should configure Nginx for a
specific server from start to end, since I don't want to search into more
roles where is Nginx configured on a specific server, it should all be at
the same place.
@Michael what do you mean "just needs to pass a parameter"? I don't
understand how this problem could be solved by one parameter? Are you
suggestion that I should use what Maciej suggested, make roles fully
configurable via variables, or did you have something different on your
mind?
On Saturday, May 10, 2014 1:45:32 AM UTC+2, Michael DeHaan wrote:
>
> " I think the most elegant way to handle this is to add a new keyword in
> the role dependency statement that would allow to override templates and
> files on a "common" role by another role that depends on it."
>
> Adding a new keyword is almost never the answer.
>
> It sounds like the OP just needs to pass a parameter into the role to me.
>
>
>
>
> On Fri, May 9, 2014 at 2:39 AM, 'Petros Moisiadis' via Ansible Project <
> ansible...@googlegroups.com <javascript:>> wrote:
>
>> On 05/07/2014 11:35 PM, Strahinja Kustudić wrote:
>>
>> I have been using Ansible for a few months now and it has been a blast. I
>> think I got the hang of how Ansible works pretty good, but I'm still not
>> sure about what is the best way to reuse roles.
>>
>> Let's take the "nginx" role as an example. We have Nginx installed on a
>> lot of servers, but besides the common steps of installing nginx, the
>> configuration files are a lot different (some servers only have http, some
>> have SSL as well, so they need certificates, different virtual hosts, etc).
>>
>> What I did is created a variable called *nginx_server_type*, which you
>> set to a server name, or group name (which shares the same configuration
>> files) and then use it like this:
>>
>> - name: Copy /etc/nginx/nginx.conf
>> template: src={{ nginx_server_type }}/etc/nginx/nginx.conf.j2
>> dest=/etc/nginx/nginx.conf
>> mode=0644
>> owner=root
>> group=root
>> notify: reload nginx
>>
>> - name: Copy /etc/nginx/
>> copy: src={{ nginx_server_type }}/etc/nginx/
>> dest=/etc/nginx/
>> notify: reload nginx
>>
>>
>> Then you need to create directories inside *templates *and *files *which
>> are called {{ nginx_server_type }} and put the configuration files in them.
>> So basically every time I need a new server, I modify a role by adding
>> template and configuration files for that server.
>>
>> This problem basically comes up for any role which is not the same for
>> all servers. Is there a better way to deal with this? How do you do it?
>> --
>> 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-proje...@googlegroups.com <javascript:>.
>> To post to this group, send email to ansible...@googlegroups.com<javascript:>
>> .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/ansible-project/228baad4-9076-4109-ab4c-9d43f75e860d%40googlegroups.com<https://groups.google.com/d/msgid/ansible-project/228baad4-9076-4109-ab4c-9d43f75e860d%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> What you want is very common. I think the most elegant way to handle this
>> is to add a new keyword in the role dependency statement that would allow
>> to override templates and files on a "common" role by another role that
>> depends on it. So, in your case you could create an "nginx_common" role as
>> well as several "nginx_sometype" roles that would depend on "nginx_common"
>> role and provide any templates/files to override the ones in the
>> "nginx_common" role. That way you do not have to "pollute" your
>> "nginx_common" role directory with templates/files that are not actually
>> "common" or conflict with each other. Instead, you keep separate
>> "nginx_sometype" roles and each one of them can provide its own set of
>> templates/files that will override the ones in "nginx_common" role "on the
>> fly".
>>
>> Look at the following thread, for a proposal and discussion around this:
>>
>> https://groups.google.com/forum/#!searchin/ansible-project/override/ansible-project/9xRyYIOdSro/KustjP725kQJ
>>
>> If you find my proposal interesting, it would probably be more
>> appropriate to make any comments at the other thread to keep relevant
>> discussion at one place.
>>
>> --
>> 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-proje...@googlegroups.com <javascript:>.
>> To post to this group, send email to ansible...@googlegroups.com<javascript:>
>> .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/ansible-project/536C782C.2050504%40yahoo.gr<https://groups.google.com/d/msgid/ansible-project/536C782C.2050504%40yahoo.gr?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/0405b59c-b99b-4b57-a624-f3643ea80d12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
