Configuring Model Settings


#1

Hey

I am trying to figure out how to apply the settings mentioned in “Configuring Models” and was wondering how these are applied in charms.

Any guidance would be appreciated


#2

Can you mention what config you’re looking into that will have an affect on the charms?


#3

Sure specifically “juju-http{s}-proxy” how is this applied within Charms?


#4

From my experience in the field, juju-http(s)-proxy variables do not affect the http(s)-proxy settings for individual charms.

It’s used for juju’s internal communications, IIUC. You’ll still need to set each individual charm’s http(s)-proxy settings if you should need proxy settings for your services to talk with other related services or contact the internet.

apt-http(s)-proxy, however, will cover all apt commands for all charms (except for add-key and apt-add-repository, which requires manual intervention currently. see lp#1433761) and these will be updated on each machine deployed in the model as it is applied to the model-config.

If you should choose to use http(s)-proxy variables, this will apply to everything running on the machine, and will put proxy calls between all of your outbound http(s) calls, including between machines in your model which probably shouldn’t be proxied.

So, the application of model-configs is generally immediate (save for things like cloudinit-userdata), but the config you’re interested in may not provide the functionality you intend.


#5

Yep exactly. It helps make sure that you can set different paths for management plane traffic vs workloads which might need to hit internal or different proxies for applications/etc.

The juju variables are available if you want to set/read them in charms but the generic ones are more likely to be picked up by tools/software that are proxy aware and looking in the standard locations for proxy details.


#6

OK Guys cheers for your responses. I found out in the end that they are being utilised in some charms to override variables, and it was this I was looking for.


#7

Charms can introspect the JUJU_HTTP_PROXY settings if they chose to. The issue is that because NO_PROXY isn’t implemented very well (doesn’t support ranges/CIDR), the request was to have a way to inform charms that they might be interested in toggling proxy settings. (The charm can introspect JUJU_HTTP_PROXY and JUJU_NO_PROXY to decide whether they will be doing internal communication and should not set the proxy or doing external communication and should enable it.)

I don’t know if any charms have actually implemented the logic, though I think the Openstack charms are considering it. (It was an attempt at handling private firewalls/proxies.)


#8

Hey,

After some investigation I found out how to utilise the variables, they’re picked up by charm helpers.

If you wish to know more, there’s a useful PR here

Cheers!