1ca4bd0ab9
In some cases software deliberately allows drop-in config file usage
capabilities, for example, when it comes to enforcing policy, the
desired behavior varies from an operator to operator. For that reason it
is sometimes desirable to supply custom templates via config options.
Another use-case is templates that are passed from subordinates for a
primary charm to render.
Given that properties and desired adapters can be arbitrary the change
uses a dict of meta tuples of the following format to render templates
from strings based on adapter properties:
{config_file_path: (relation_name, adapter property)}
relation names must be normalized (lowercase, underscores instead of
dashes. "options" relation name is used for a config adapter as usual.
In summary a string config file path should be used:
1. in the restart_map for a given derived class;
2. in string_templates dict as a key for a meta tuple
Change-Id: Ic85b22d0e5d497c49c75243e3c280140f940df66
Closes-Bug: #1741723
|
||
|---|---|---|
| .. | ||
| charms_openstack | ||
| __init__.py | ||
| odl_responses.py | ||
| pci_responses.py | ||
| test_charms_openstack_adapters.py | ||
| test_charms_openstack_devices_pci.py | ||
| test_charms_openstack_ip.py | ||
| test_charms_openstack_sdn_odl.py | ||
| test_charms_openstack_sdn_ovs.py | ||
| test_charms_openstack_test_utils.py | ||
| utils.py | ||