Now, the bootstrap works (with Candid etc.) and ‘sometimes’ on the default model.
However: when I create new models with “juju add-model”, I can’t seem to get the “datastore” and primary-network to be inherited down to the new models I create from this controller. This prevents new machines from being deployed.
My question is:
"How do I include configuration keys to apply for all new model creations - ideally part of the bootstrap config yaml?
I know how to set these values on a “per model basis”, like:
$ juju model-config datastore=H280-VIC847-0001
WARNING key "datastore" is not defined in the current model configuration: possible misspelling
$ juju model-config primary-network=VLAN_802
WARNING key "primary-network" is not defined in the current model configuration: possible misspelling
Then I’m all good.
But I need this to be applied to all models being created from this controller.
I’ve experimented with this a bit, and figured out a way to at least have all future models on a given controller have the configuration that you want. After the bootstrap is complete, issue these commands:
Note that if you switch to another controller, it will not have these defaults (which is most likely the way you want it anyway).
Also have a look at “juju help bootstrap”. It is possible to add a parameter called model-defaults there, like this:
–model-default (= )
Specify a configuration file, or one or more configuration
options to be set for all models, unless otherwise specified
(–model-default config.yaml [–model-default key=value …])
During our trials on bootstrapping a vsphere type controller as above, we noticed that the first “default” model had the values set when passing command line parameters. So, then deployment works.
However, when we removed the “default” model and spawned another model with “juju add-model foobar”, the values for “datastore” and “primary-network” didn’t seem to be added. We didn’t notice this first, since the “default” model worked at first.
Later, we wanted to try to put all configuration into a “config.yaml” file which is the basis for the last post. I fail getting those “datastore” and “primary-network” keys into the default model using a config.yaml. Hence the phrase “sometimes”, which should be:
“When using command line parameters -> it seemes to work”
“When putting it into a config.yaml” -> it doesnt seem to work"
But, for me to be able to work this out, I need to know that I’m producing a correct “config.yaml” to rule out that I’m the one making errors.
@hallback that seems to be the way. I’ll try it on the 7:th january when back at work.
— update — @hallback suggestion made the trick. It works perfectly placing these key: values in controller and model-defaults yaml files and getting the models to properly inherit the settings accordingly after bootstrap. @rick_h
Cool, let us know how it goes. model-defaults are definitely the way to go. There’s some discussion on the right/wrong ways to go about this tbh and so sometimes it’s our fault that folks end up holding it wrong.
The update is that I’ve got it to work now and will try put together a guide/tutorial on how to achieve it with @hallback during next week.
Also, we learned alot from this experience about how to differentiate between access to the controller vs access to the models. How to slice the management of account access between different users will be something we need to think about aswell.
