Closed simonspa closed 5 years ago
I had the same dilemma in the past for many other roles as well. I have concluded that the best approach is to handle configuration minimally, even have a "text" variable that will be spat in a config file. Some of the reasons are:
nextcloud_config
. For instance, in:you can see how I do it in my own playbook, where I re-use variables set for other roles (that install apache, mysql) to configure this role. Re-using the redis role's variables could be similar.
vars
lookup, adding defaults, conditionals, etc. It will also make any templates longer and harder to read.nextcloud_config
dict makes it easy to manipulate them (eg merge user config with defauts, loop, ...)occ
to import it than looping and using config:set
for each one of them.Of course, if there is a part of the config that could be split out of the general nextcloud_config
dict to add functionality, we should do this. For example, in another role of mine, I have a general config
dict were all the configuraion could go in unconditionally. But I also provide separate variables for a part of the config that handles TLS certificates/keys. This is in addition to the config
dict. I do this because the role will also have to handle certiicate generation, putting into place, setting permissions, etc. Having them as separate variables make it easier to perform these tasks, check the variable values and expose them as functionality to the user. If I didn't have them as separate variables, I would have to dig into the config
dict, check if they are there, inform the user, etc.
For the redis configuration, I cannot see how this could be the case, but I could of course be mistaken. For the email part, we could maybe have them exposed as separate variables to add some more value to the user. But I don't know what this could be. I am open and willing to add such logic if it adds value.
About the magic part you mention, I would like to keep the role totally independent from other roles and not promote specific 3rd party roles. As I showed in the snippet above, it is trivial for the user to re-use variables from other roles to configure this role. Adding logic to support 3rrd party roles to make it a tiny little easier for the user is not in my opinion a good investment of resources, plus it adds one more thing that we will need to keep track of for future changes. Leaving it to the user, the playbook is built in a modular way and the user can easily build a chain of roles where a role can be replaced by another, each user taking care of their use case and role ecosystem.
I was wondering what the best way is to configure a memcache like Redis. I course I could simply add the relevant parameters to
nextcloud_config
but we could also add some logic, exposing the individual configuration parameters and then adding them to nextcloud usingphp occ config:set
?I was thinking of e.g. Redis, mail SMTP etc.
With this we could also add some magic like checking if variables from
geerlinguy.redis
are around and automatically configure it appropriately (redis_requirepass
etc).Let me know what you think.