And yet it appears that Apache and Nginx the two examples raised so far do both include an “include” mechanism. For those that don’t it is always (and I don’t think that has been emphasised enough yet) possible to use Assemble to add together multiple configuration fragments created by different roles…
e.g. My main widget role puts down some basic configuration pieces, my widget instance role adds some more bits to the same directory, my gadget role adds a few more bits, and finally a configure role pulls all of the pieces together into one configuration file. If something changes it’s piece the only parts that would run would be the relevant role and the configure role to pull all of the new bits together. If you don’t like the idea of having a separate role then you make sure that the main widget role is called last and it does the assembly… or you run the playbook twice (or more) until it settles down.
Adam
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.
I understand what you are saying, but unless the role that you run first (avoiding the d word) knows to expect a template from the later role then you have an issue. If all roles were written to add fragments and assemble configuration files then they could work together (or for applications that have configuration directories that’s already solved for you). But then you are either going to have to go in and retrofit all existing roles or only work with a subset. There is no enforced coding standard for roles so I think that we are going to have to live with the current situation.
If you write your roles to be accepting of fragments then that’s the best that you can do…
Adam
I’m not at all saying that the role HAS to know about the template path, I’m saying that during the passing of the parameters of that role you could pass in a string that represents a file and that file could either exist in the role that has the dependency declaration or the role that you’re calling. It’s a simple change to the template path when you’re calling roles within the dependency list. It could allow you to override templates that are present in the dependant roles without having to copy out, or change a potentially third party role. This also has the benefit in that you don’t change templates or files within roles, and can potentially update them if they’re from a third party without causing any conflicts or storing your own template files within that role.
To me it seems the role should be responsible for it’s own configuration files and setting their parameters rather than dropping files into directories and calling handlers externally, but perhaps that’s just my perception coming from other systems?