If I'm understanding you correctly, the ideal implementation for this would
be something like:
@hook('upgrade-charm')
@when('nrpe.available')
def update_checks(nrpe):
nrpe.remove_check(name='to-be-removed')
nrpe.add_check(...)
However, because of a bug / implementation detail (
https://github.com/juju-solutions/charms.reactive/issues/12), you will
currently have to inline the state lookup instead of using the @when
decorator:
from charms.reactive.relations import RelationBase
@hook('upgrade-charm')
def update_checks():
nrpe = RelationBase.from_state('nrpe.available')
if nrpe:
nrpe.remove_check(name='to-be-removed')
nrpe.add_check(...)
There was some discussion recently where Stuart gave me some insight which
I think will allow a fix for that bug (finally!) but I haven't yet had a
chance to dive in to it.
On Fri, Jul 8, 2016 at 1:11 PM, Casey Marshall wrote:
> I need some help with understanding the best way to manage relation info
> across an application's lifecycle with the reactive framework.
>
> I'll start with the situation that brings me here:
>
> I have a reactive charm that provides some fairly static relation info:
> nagios checks over the nrpe-external-master interface. This charm is
> deployed and related to the nrpe subordinate.
>
> My charm adds the nagios checks it supports when joining the relation, and
> removes them when it departs.
>
> Now, in a new version of my charm, I want to add or remove these nagios
> checks, which means I need to change the relation data. What is the best
> way to do this with the reactive framework? It would be ideal to trigger a
> "conversation" to happen, that would use the same relation state handlers I
> already have in my charm, but I'm not sure how to do this.
>
> I could see a similar situation for other interfaces. http, for example,
> where you have to set extra info in YAML strings for load-balancing with
> apache2 and haproxy. It's easy to imagine needing to change those
> parameters across charm upgrades over time.
>
> I'm trying to avoid the brute-force option, which is to destroy and re-add
> the relation. That works, but seems heavy-handed and wrong.
>
> -Casey
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
