So I investigated this by just creating a charm that has very simple properties:
class Ubuntu(charm.CharmBase):
"""The simplest of charms that just gets Ubuntu up and running.
"""
...
def _on_settings_changed(self, event):
sub = subprocess.run('leader-get', capture_output=True) logging.info('leader-settings-changed for %s:\nout: %r\nerr: %r', self.unit.name, sub.stdout, sub.stderr)
def _on_elected(self, event):
sub = subprocess.run('leader-get', capture_output=True) logging.info('leader-elected for %s:\nout: %r\nerr: %r', self.unit.name, sub.stdout, sub.stderr)
I did see a leader-settings-change after upgrade-charm completed (which doesn't seem correct, but isn't strictly wrong nor should be happening often).
I also tested whether running `juju run --unit X -- leader-set leader_id=SAME_VALUE`
and I wasn't able to trigger a second leader-settings-changed event (so setting a field to the same value as it already has *shouldn't* trigger a leader-settings-changed event.)
I did also do the same thing as the linked charm where in update-status and in leader-elected it sets leader_id. In that case, I still don't see lots of calls to leader-settings-changed. (this is with a local test controller running a pre-2.9.30 Juju).
I'll try running it with 2.9.27 but I don't think we changed anything in this area.
So I investigated this by just creating a charm that has very simple properties: charm.CharmBase ):
class Ubuntu(
"""The simplest of charms that just gets Ubuntu up and running.
"""
def __init__(self, framework, *args):
super( ).__init_ _(framework, *args)
...
self.framework .observe( self.on. update_ status, self._on_ update_ status)
self.framework .observe( self.on. leader_ settings_ changed, self._on_ settings_ changed)
self.framework .observe( self.on. leader_ elected, self._on_elected) status( self, event):
self.model. unit.status = model.ActiveStatus( .format( load1min, load5min, load15min)) run('leader- get', capture_ output= True)
logging. info('update- status for %s, is-leader: %s:\nout: %r\nerr: %r',
self. unit.name, self.unit. is_leader( ), sub.stdout, sub.stderr)
...
...
def _on_update_
load1min, load5min, load15min = os.getloadavg()
'load: {:.2f} {:.2f} {:.2f}'
sub = subprocess.
... changed( self, event): run('leader- get', capture_ output= True)
logging. info('leader- settings- changed for %s:\nout: %r\nerr: %r', self.unit.name, sub.stdout, sub.stderr)
def _on_settings_
sub = subprocess.
def _on_elected(self, event): run('leader- get', capture_ output= True)
logging. info('leader- elected for %s:\nout: %r\nerr: %r', self.unit.name, sub.stdout, sub.stderr)
sub = subprocess.
I did see a leader- settings- change after upgrade-charm completed (which doesn't seem correct, but isn't strictly wrong nor should be happening often).
I also tested whether running `juju run --unit X -- leader-set leader_ id=SAME_ VALUE`
and I wasn't able to trigger a second leader- settings- changed event (so setting a field to the same value as it already has *shouldn't* trigger a leader- settings- changed event.)
I did also do the same thing as the linked charm where in update-status and in leader-elected it sets leader_id. In that case, I still don't see lots of calls to leader- settings- changed. (this is with a local test controller running a pre-2.9.30 Juju).
I'll try running it with 2.9.27 but I don't think we changed anything in this area.