Just to confirm, I wasn't suggesting any form of inheritance in any way, it's just that quite often when you want to include dependencies then you may want to pass a template to that particular role. In many circumstances (such as nginx) it's not possible to provide this via yaml configuration simply because of the complexity of that configuration.
I completely agree with the way that dependencies currently work, I just think there's a better way to pass information to these dependencies so that you can represent data in ways other than yaml. At the moment as I say it is possible, it's just that you have to provide the absolute path to the template. The way that I saw it working was that the role has it's dependencies, and the path of the role that defined those dependencies is added to the normal template path. To give a completely practical example say you have a graphite installation, and you want graphite to sit behind nginx. So you create an example.graphite role that has a meta file that lists the dependency of example.nginx. Now you want to provide a conf file for that graphite installation, now lets say that you've got a few conditionals in your config file, there's no real clean way to provide this information via yaml, so you basically want to create a template file for your example.graphite installation. The logical place for this is obviously the example.graphite/templates directory. But in your example.nginx dependency you need to accept in the template file, at the moment the only way is to provide the absolute path to this file. What may benefit re-usability is just to accept a string that represents a file within the example.graphite/templates directory, if that doesn't exist fall back to example.nginx/templates and if that doesn't exist, fail. This also has a lot of benefits for galaxy role re-usability, because evidently one of the issues with Puppet's Forge is that a lot of these modules are un-usable because they don't accept the parameter in that you need to set so you end up copying it and then hacking with it to add in the option that you need. But if you just accept a template in then the user has full control over what they need to set and this issue with the lack of a configurable option disappears. On Tuesday, 27 May 2014 18:26:04 UTC+1, Michael DeHaan wrote: > > I don't understand what you are suggesting to implement, though this is > probably a good discussion for ansible-devel instead of the main list. > > We would like to see what syntax you are proposing though it *sounds* like > you might be saying to search the various role dependency chain items to > find the first file up the chain starting at the current role. > > Really, role deps shouldn't be looked at like inheritance though - they > are simply NOT inheritance. They are things to do *first*. > > It might be better to pass a parameter into the role instead (like you > have) with what filename to use, I'm unclear as to why you think it needs > an absolute path though. > > > > > > On Tue, May 27, 2014 at 5:53 AM, Paul Oyston <[email protected]<javascript:> > > wrote: > >> Hi guys, >> >> I had a bit of an idea surrounding the template and file path for >> dependencies, wondering what everyone thinks of this. >> >> At the moment when you use meta/main.yml - dependencies the template path >> and file path is set to the role that you're running in. For example if you >> were to use a example.nginx role the template path would be something like >> /etc/ansible/roles/example.nginx/templates. >> >> When you're calling dependencies it's likely that you may want to >> override a template or pass a template in to the role. For example you may >> wish to do something like: >> >> # file: /etc/ansible/roles/example.app/meta/main.yml >> --- >> dependencies: >> - role: example.nginx >> server_template: server.conf.j2 >> >> >> Where the server.conf.j2 file is contained within the example.app role. >> At the moment the only workaround to this is to use the absolute path which >> may not be very portable. >> >> # file: /etc/ansible/roles/example.app/meta/main.yml >> --- >> dependencies: >> - role: example.nginx >> server_template: /etc/ansible/roles/example.app/templates/server.conf >> .j2 >> >> I don't mind implementing this feature myself if it's considered to be a >> good idea. >> >> -- >> 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] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/f4f5ca9c-fc82-4d55-a471-2f3cdee70f03%40googlegroups.com<https://groups.google.com/d/msgid/ansible-project/f4f5ca9c-fc82-4d55-a471-2f3cdee70f03%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/5ccd7d8c-11ce-4034-b6fc-dc2325af0ba2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
