Merge lp:~thedac/charm-helpers/set-primary-charm-on-nrpe-relation into lp:charm-helpers
Status: | Needs review |
---|---|
Proposed branch: | lp:~thedac/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:~thedac/charm-helpers/set-primary-charm-on-nrpe-relation |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Stuart Bishop (community) | Disapprove | ||
Review via email: mp+256057@code.launchpad.net |
Description of the change
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{,-
Unmerged revisions
- 351. By David Ames
-
Document the primary setting on NRPE
- 350. By David Ames
-
Explicitly set when a charm is the primary charm (vs a subordinate charm) in the npre-external-
master relation.
For use when multiple charms primary and subordinate are related to nrpe{,-external- master} on the same unit.
The default is set to True as this is the case 99% of the time.
Only subordinate charms which are related to nrpe{,-external- master} need set primary=False on the relation.
The code looks good. The test changes are more dubious - you have added a relation_set call, but the new code path is not being tested. relation_set is already mocked in the test harness, so something like the following:
def test_init_ primary( self): primary= sentinel. primary)
self.assertEqu al(checker. primary, sentinel.primary)
self.patched[ 'relation_ set'].assert_ called_ once_with( relation_ settings= {'primary' : sentinel.primary})
from unittest.mock import sentinel
checker = nrpe.NRPE(