Comment 8 for bug 1835050

In a general sense, if a charm is exposed data in a hook, then that hook
should be triggered again if the data it was depending upon changes.
We've been having some internal discussions about having a "charm-context"
sort of hook tool, that would give the aggregated set of information
(across all relations, across charm config, etc). That might be a clearer
point where we can build up "this is the context that the charm cares
about", and when that changes, we reinvoke a hook. I would hesitate to just
fire config-changed, as we just did a lot of work to reduce how often
config-changed triggers due to charms that restart their applications on
any config-changed fire.
Certainly a hook *should* be triggered if the information that we last told
a charm is out-of-date.

On Wed, Jul 3, 2019 at 12:01 PM Peter De Sousa <email address hidden>
wrote:

> @Anastasia
>
> Please clarify what version of Juju you are using?
>
> 2.7-beta1-cosmic-amd64
>
> What provider did you deploy your models to?
> maas
>
> What charms are you using?
>
> - https://github.com/charmed-kubernetes/charm-docker
> - https://github.com/charmed-kubernetes/charm-containerd
>
> 1. Deploy the latest Canonical Kubernetes bundle
> 2. deploy either of the above charms
> 3. then attempt to change juju-http(s)-proxy keys.
> 4. run model-config and observe model update
> 5. ssh into either of nodes (worker or master) and check the service file
> 5a. docker: /lib/systemd/system/docker.service
> 5b. containerd: /etc/systemd/system/containerd.service.d/proxy.conf
> Oberve proxy is not there.
> 6. change http_proxy key on the docker/containerd charm - observer config
> changes.
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1835050
>
> Title:
> juju-http(s)-proxy model config changes do not trigger config hooks
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1835050/+subscriptions
>