If we don't allow subordinates to change default settings in local_settings.py, we should be able to at least avoid some conflicts in the case where multiple subordinate charms are deployed.
There still seems to be opportunity for conflicts and precedence issues if multiple subordinates are deployed and I'm not sure the best way to avoid those other than some general guidance in the openstack-dashboard README to help developers of subordinate plugins best avoid conflicts.
I'm wondering if we can limit subordinate charms to only updating pluggable settings by adding *.py files to openstack_ dashboard/ local/enabled as described here: docs.openstack. org/developer/ horizon/ topics/ settings. html#pluggable- settings- label
http://
If we don't allow subordinates to change default settings in local_settings.py, we should be able to at least avoid some conflicts in the case where multiple subordinate charms are deployed.
There still seems to be opportunity for conflicts and precedence issues if multiple subordinates are deployed and I'm not sure the best way to avoid those other than some general guidance in the openstack-dashboard README to help developers of subordinate plugins best avoid conflicts.