* Add nextcloud_container_image_customizations_smb_enabled: true to configuration options
* revised variable to use "samba" not "smb"
* Move Samba for Nextcloud instructions into their own section
This keeps the initial vars.yml sample for installing Nextcloud minimal.
Samba is a rarely used optional feature and has no business being in the initial minimal configuration sample.
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
These are blind adjustements, without having tested them.
Funkwhale runs multiple containers and it's possible that a few of the
others (e.g. the Celery worker) also need access to Redis. If so,
additional adjustments would be necessary.
The playbook can now optimize itself based on the enabled components in
for all hosts in the inventory (`just optimize`) or for a specific host
(`just optimize-for-host HOSTNAME`).
The optimized playbook will have:
- fewer requirements (fewer roles need to be installed by `just roles`)
- a shorter and quicker to evaluate `group_vars/mash_servers` file
- a `setup.yml` file which includes less roles
Running the playbook optimized is still work in progress.
There still probably exist various role dependencies in the group-vars file, etc.
The `optimize-reset` command aims to restore your playbook to a
non-optimized state, which should work as before (and not experience bugs).
The playbook takes care to notice of changes to the various files in
`templates/` (`setup.yml`, `requirements.yml`, `group_vars_mash_servers`)
and update your optimized or non-optimized copies that are derived from
these templates. To do this, it keeps `.srchash` files in the `run/` directory.
When it notices a change in the source file's hash (by comparing to the `.srchash` file),
it will update you to the new template.
Optimization state is stored in a file in `run/` as well (`optimization-vars-files.state`).
Should the playbook notice changes in the source `template/` files, it
should update you and re-optimize using the same parameters as before (read from the state file).
In the future, we'll also have optional optimization steps, which could
trim down `setup.yml` based on the components being used.
Related to e2132a3c51 which did the same
for the `requirements.yml` file.
