> > I know the initial target is for the horizon subordinate plugin charms
> > to use this, but would you mind giving an example of how horizon would use
> it?
>
> Sure. The charm would register a pattern config:
>
> > register_config('/path/to/dashboard/enabled/_{}_juju_{}.py')
>
> Then,
>
> > class RouterSettingContext(OSPatternContextGenerator):
> > def __call__(self):
> > ctxt = {
> > (40, 'router'): {'DISABLED': False if config('profile') in
> ['cisco'] else True}
> > }
> > return ctxt
>
> and, for example
> > class PluginContext(OSPatternContextGenerator):
> > def __call__(self):
> > # ...
> > ctxt = {}
> > for rid in relation_ids('plugin'):
> > # ...
> > rdata = relation_get(rid=rid, unit=unit)
> > ctxt[(rdata['priority'], unit): {'DASHBOARD':
> rdata['DASHBOARD'],
> > 'DISABLED': rdata['DISABLED'],
> > # ...
> > return ctxt
>
> This would result in generating files, say:
>
> > /path/to/config/enabled/_40_juju_router.py
> > /path/to/config/enabled/_99_juju_horizon-contrail.py
>
> In PluginContext I can then warn about conflicts etc. Multiple subordinates
> could even override one another.
>
> HTH, let me know if I should explain more of this in the docstring.
Thanks for the explanation. I'm wondering if this can be solved without adding the pattern context code. I was just looking at neutron-openvswitch, which is a subordinate charm. For example it has:
> > I know the initial target is for the horizon subordinate plugin charms config( '/path/ to/dashboard/ enabled/ _{}_juju_ {}.py') ntext(OSPattern ContextGenerato r): OSPatternContex tGenerator) : ids('plugin' ): get(rid= rid, unit=unit) 'priority' ], unit): {'DASHBOARD': config/ enabled/ _40_juju_ router. py config/ enabled/ _99_juju_ horizon- contrail. py
> > to use this, but would you mind giving an example of how horizon would use
> it?
>
> Sure. The charm would register a pattern config:
>
> > register_
>
> Then,
>
> > class RouterSettingCo
> > def __call__(self):
> > ctxt = {
> > (40, 'router'): {'DISABLED': False if config('profile') in
> ['cisco'] else True}
> > }
> > return ctxt
>
> and, for example
> > class PluginContext(
> > def __call__(self):
> > # ...
> > ctxt = {}
> > for rid in relation_
> > # ...
> > rdata = relation_
> > ctxt[(rdata[
> rdata['DASHBOARD'],
> > 'DISABLED': rdata['DISABLED'],
> > # ...
> > return ctxt
>
> This would result in generating files, say:
>
> > /path/to/
> > /path/to/
>
> In PluginContext I can then warn about conflicts etc. Multiple subordinates
> could even override one another.
>
> HTH, let me know if I should explain more of this in the docstring.
Thanks for the explanation. I'm wondering if this can be solved without adding the pattern context code. I was just looking at neutron- openvswitch, which is a subordinate charm. For example it has:
BASE_RESOURCE_MAP = OrderedDict([
'services' : ['neutron- plugin- openvswitch- agent'] ,
'contexts' : [neutron_ ovs_context. OVSPluginContex t(),
context. AMQPContext( ssl_dir= NEUTRON_ CONF_DIR) ,
context. ZeroMQContext( ),
context. NotificationDri verContext( )],
(NEUTRON_CONF, {
}),
...
Can you do something similar for subordinate horizon charms? In other words, the subordinate charms would write the plugin file themselves.
For example. horizon subordinate 1 could have:
BASE_RESOURCE_MAP = OrderedDict([ path/to/ config/ enabled/ _40_juju_ router. py, {
'contexts' : [RouterContext()],
(/
}),
...
and horizon subordinate 2 could have:
BASE_RESOURCE_MAP = OrderedDict([ path/to/ config/ enabled/ /_99_juju_ horizon- contrail. py, {
'contexts' : [ContrailContex t()],
(/
}),
...
You could make the precedence (ie. 40 and 99) more flexibly in the subordinate charm and allow them to be changed via a config option.