nkakouros-original / ansible-role-nextcloud

An Ansible role to install Nextcloud
GNU General Public License v3.0
11 stars 5 forks source link

Setting Memcache and other config variables #25

Closed simonspa closed 5 years ago

simonspa commented 5 years ago

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 using php 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.

nkakouros commented 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:

https://github.com/nkakouros-original/ansible-role-nextcloud/blob/6201c7ac8506e2973d68c88af369e7cd5eb4a2bf/molecule/default/playbook.yml#L7-L22

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.

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.