Open jamesbeedy opened 6 years ago
Those handlers are for backwards compatibility. Essentially, they translate the new, automatically managed endpoint.http.joined
flag into the existing http.available
flag that the existing interface layer already uses. This way, no charms using the interface layer need be updated or care if this interface layer is updated. (At least, that's the goal; if there are any changes that have to be made in the charm layer for that PR, then we need to fix that.)
I've run into an issue where upgrading a charm removes other interfaces' states.
The steps to reproduce are:
juju deploy cs:nagios
juju deploy cs:nrpe
juju deploy cs:grafana
juju add-relation nagios nrpe
juju add-relation grafana nrpe
The nrpe-external-master.available
flag is set. When juju upgrade-charm cs:grafana
is run, the flag is cleared. Debug logs don't show the removal, only the call to hooks/relations/http/provides.py:15:broken:website
, which should no affect but website.available
.
See https://pastebin.ubuntu.com/p/2smQt4X3Wd/
PS: I see the same issue when I run juju add-relation grafana:grafana-source prometheus
. By upgrading the grafana
charm, grafana-source.available
is not there anymore (checked via juju run -u grafana/0 "chams.reactive -p get_flags"
).
PS2: Both nrpe-external-master
and grafana-source
interfaces react to hooks, not states
concerning https://github.com/juju-solutions/interface-http/blob/endpoints/provides.py#L9,L15
The above snippet is confusing because it gives the impression that the reactive framework is just managing a single flag 'endpoint.{endpoint_name}.joined'.
https://github.com/juju-solutions/interface-http/blob/endpoints/requires.py#L13 is also confusing.
Should we not be reacting to the appropriate respective flags for broken, changed, joined, departed, instead of doing whats been done ^?