This is confirmed to be still an ongoing issue with Juju 3.4 release.
I have found a temporary workaround, with the option "--controller-charm-path" although this is not perfectly ideal.
This is for a deployment with Juju 3.4, with having all your proxy settings (with juju-http(s)-proxy) in the default-model configuration as a file in "juju-default-config.yaml"
* download the controller charm for the wanted release of Juju
--> juju download juju-controller --channel 3.4/stable --base ubuntu@22.04
* enable-ha with the controllers
--> juju enable-ha
* After all the controllers are now working HA and "juju controllers --refresh" do show the scale of 3/3
--> juju refresh -m controller controller --switch ch:juju-controller --channel 3.4/stable
After this all models, including the controller model, will have the juju-http(s)-proxy being defined and used
This is confirmed to be still an ongoing issue with Juju 3.4 release.
I have found a temporary workaround, with the option "--controller- charm-path" although this is not perfectly ideal. config. yaml"
This is for a deployment with Juju 3.4, with having all your proxy settings (with juju-http(s)-proxy) in the default-model configuration as a file in "juju-default-
* download the controller charm for the wanted release of Juju
--> juju download juju-controller --channel 3.4/stable --base ubuntu@22.04
* bootstrap the controller charm-path ./juju- controller_ r79.charm --model-default ./juju- default- config. yaml maas_cloud maas-juju-3-4
--> juju bootstrap --bootstrap-base ubuntu@22.04 --controller-
* enable-ha with the controllers
--> juju enable-ha
* After all the controllers are now working HA and "juju controllers --refresh" do show the scale of 3/3
--> juju refresh -m controller controller --switch ch:juju-controller --channel 3.4/stable
After this all models, including the controller model, will have the juju-http(s)-proxy being defined and used