Better handling of mutable configs

[almahmoud]

xref: https://github.com/galaxyproject/galaxy-helm/issues/118 My current plan is to eliminate the manual listings in: https://github.com/galaxyproject/galaxy-helm/blob/master/galaxy/templates/_helpers.tpl#L80 and have two different sections in values: configs and managedConfigs (https://github.com/galaxyproject/galaxy/pull/9444)

managedConfigs will not be editable via pure upgrades (i.e. via just configmap changes, because they won't propagate since the init container does not re-copy) i.e. not via CloudMan/Helmsman (at least for the beginning, although we could implement logic to make them editable there as well, but we'd need to start from the one in the mutable config directory, rather than the configmap, and make sure the upgrade is replacing in the mutable config directory). Also, the init container will automatically deal with all managedConfigs, and put them all in the mutable config directory, rather than listing them by name as is now.

[nuwang]

See the general point, but specifically wrt to sanitize_whitelist - does it need to be mutable? What if we made it non-mutable?

[dannon]

@nuwang Not sure I follow -- how would that work, just disable the galaxy writes to the file? Right now the admin interface at <galaxy-instance>/admin/sanitize_whitelist/ writes to this file when administrators select which tools should be whitelisted.

[almahmoud]

The only way we can make it immutable is if we somehow disable the UI to add tools to it, which I would think is not ideal cause we'd force the admin to manually add them to the file via CloudMan and trigger an unnecessary upgrade in the process