On 14/06/16 15:06, Mark Shuttleworth wrote: > On 13/06/16 14:35, Ian Booth wrote: >> The above are model commands. So we need a way to set foo=bar on the >> controller >> itself (ie update the shared controller wide config). What are you proposing? >> Did you intend that setting foo on the controller model would satisfy the >> requirement? That seems to be wrong for 2 reasons: > > I think we are conflating two ideas: > > * properties of the controller > * default model properties > > In the latter case, you are describing these are "set foo=bar on the > controller itself" but it is not actually a controller property, it's > just that you're using the "controller" as a way to describe "the place > where the model defaults are for this controller". > > That's why I prefer: > > set-controller-config > set-model-config > set-model-default >
I like the above too. But some folks we've talked to have thought that introducing 3 commands (the ones above) is cognitive overhead. Hence this discussion to tease out the best approach. > The last one makes it clear that what you are setting is a *model > property* it's just a model property that will be used when the model > hasn't overridden it. > +1 Agree 100%. If the guidance is to go with 3 commands that is awesome as that's the direction we've been heading towards with this work. > One last thing to discuss is whether some of these model properties are > "forked" at model instance time, in which case setting the model-default > will not affect an existing model, or whether they are run-time > real-time, updating the model-default will update all existing models > that have not overridden that config. > The intent at this point is not to fork, so the latter case above. If you want to ensure any default changes don't affect your model, you can always "lock down" any relevant properties by setting them explicitly on the model. I think this will be the most common use case. It's easy enough to change the implementation before rc once we get feedback. If the intent is to make some properties forked and others not, we'd need to consider adding additional schema metadata to tag relevant properties. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
