Merge lp:~axino/charm-helpers/set-primary-charm-on-nrpe-relation into lp:charm-helpers
Status: | Merged |
---|---|
Merged at revision: | 621 |
Proposed branch: | lp:~axino/charm-helpers/set-primary-charm-on-nrpe-relation |
Merge into: | lp:charm-helpers |
Diff against target: |
66 lines (+18/-4) 2 files modified
charmhelpers/contrib/charmsupport/nrpe.py (+15/-1) tests/contrib/charmsupport/test_nrpe.py (+3/-3) |
To merge this branch: | bzr merge lp:~axino/charm-helpers/set-primary-charm-on-nrpe-relation |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Stuart Bishop (community) | Approve | ||
Review via email: mp+290097@code.launchpad.net |
Description of the change
(Stolen from https:/
In IS we have scenarios where a unit may have its primary charm and multiple subordinate charms related to nrpe{,-
The nrpe-external-
This leads to situations where the hostname generated uses the subordinate charm's service name rather than the primary charm.
The only way to guarantee that the primary charm is used, is to set the information on the relation in the charm and then test for it in the nrpe-external-
This MP is one half of the solution. Primary charms will default to True and subordinate charms can set primary=False.
Explicitly set when a charm is the primary charm (vs a subordinate charm) in the npre-external-
For use when multiple charms primary and subordinate are related to nrpe{,-
The default is set to True as this is the case 99% of the time.
Only subordinate charms which are related to nrpe{,-
Calling relation_set without an explicit relation_id only works if inside a relation hook, so that needs to be fixed (see inline comments). Otherwise looking fine.