juju-http(s)-proxy model config changes do not trigger config hooks

[Peter Jose De Sousa]

Hello,

When attempting to listen for model configuration changes inside of charms, I am unable to hook onto changes for the juju model values juju-http-proxy or juju-https-proxy. I have tried to hook onto these via config.default.http-proxy, config.juju-https-proxy, and just config.change, but neither were triggered by an update to model.

Workaround at the moment: Change http_proxy configuration keys which are overritten by these config keys.

[Anastasia (anastasia-macmood)]

@Peter De Sousa,

Please clarify what version of Juju you are using? What provider did you deploy your models to? What charms are you using?

Repro steps would be greatly appreciated as well as logs.

[Dmitrii Shcherbakov (dmitriis)]

IoW:

`juju model-config juju-https-proxy` does not result in a config-changed event raised for all units of all applications in a model.

[Anastasia (anastasia-macmood)]

I think that this is a wishlist item - config change event does not react to model config changes but to application config changes.

[Dmitrii Shcherbakov (dmitriis)]

I agree, as such model-config changes are not something charms have previously reacted to via explicit events and proxy settings are exposed via hook environment variables only.

I think we need to have a design discussion about whether we should special-case some model-config changes to trigger config-changed events or not (and then provide some other mechanism to react to those changes, e.g. a special event and something like a model-get hook tool to fetch a subset of model settings).

There is clearly a need to handle those updates as many charms are polluted with proxy config options. For better or worse it allows charms to set proxy servers on per-use-case basis but most of the charms (in my experience) actually use the same config as the one provided by juju-{http,https,no}-proxy which makes the experience of working with proxies very confusing and error-prone.

[Anastasia (anastasia-macmood)]

Agreed.

At the moment, particularly for proxy related model configs, there are
workers that will pick them up. They are machine workers, so model
machines will be aware of the change but no unit/application hooks will
be fired.

To cater for your needs, we'd need to have something that says 'I am
changing these model config values and I want applications a, b, c to be
aware (i.e. fire hooks for these units)' or something along these lines.
Definitely worth a design discussion.

[Peter Jose De Sousa (pjds)]

@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.

[John A Meinel (jameinel)]

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
>

[Tim Penhey (thumper)]

We should create a watcher that the uniter hooks into its analysis criteria that gets told when the proxy values change.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.