Model config
Hi folks, We're in the midst of making some changes to model configuration in Juju 2.0, separating out things that are not model specific from those that are. For many things this is very clear-cut, and for other things not so much. For example, api-port and state-port are controller-specific, so we'll be moving them from model config to a new controller config collection. The end goal is that you'll no longer see those when you type "juju get-model-config" (there will be a separate command to get controller attributes such as these), though we're not quite there yet. We also think there are some attributes that people will want to set across all models, but are not necessarily related to the *controller*. For example, http-proxy, apt-http-proxy, and their siblings. I expect that if anyone is setting these particular attributes, they are doing so for *all* models, as they're operating within a private cloud with limited network access. Does anyone have a real, uncontrived use-case for configuring proxy settings on a per-model basis? Cheers, Andrew -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Model config
Hello all, I am testing/validating with apt-mirror atm. Doing so my expectation would be to set this at the controller level and have the capacity to override per model (or user). Why ? response staging. People taking the burden of managing mirrors do so to control their environment. Which means they will need to test an update before committing to prod. This is the reason there is a transactionnal/staging in https://launchpad.net/ubuntu-cloud-mirrors which the way I manage the mirrors themselves. Hope this helps, On Wed, Jun 8, 2016 at 11:41 AM, Andrew Wilkins wrote: > Hi folks, > > We're in the midst of making some changes to model configuration in Juju > 2.0, separating out things that are not model specific from those that are. > For many things this is very clear-cut, and for other things not so much. > > For example, api-port and state-port are controller-specific, so we'll be > moving them from model config to a new controller config collection. The end > goal is that you'll no longer see those when you type "juju > get-model-config" (there will be a separate command to get controller > attributes such as these), though we're not quite there yet. > > We also think there are some attributes that people will want to set across > all models, but are not necessarily related to the *controller*. For > example, http-proxy, apt-http-proxy, and their siblings. I expect that if > anyone is setting these particular attributes, they are doing so for *all* > models, as they're operating within a private cloud with limited network > access. > > Does anyone have a real, uncontrived use-case for configuring proxy settings > on a per-model basis? > > Cheers, > Andrew > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > -- Best Regards, Nicolas Thomas http://insights.ubuntu.com/?p=889 EMEA Solution Architect Canonical GPG FPR: D592 4185 F099 9031 6590 6292 492F C740 F03A 7EB9 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Model config
juju set-model-defaults juju set-model-config juju set-controller-config Have we a strong preference for get/set names, or could we just use "model-config" and "model-defaults" as read/write commands? Mark On 08/06/16 18:41, Andrew Wilkins wrote: > Hi folks, > > We're in the midst of making some changes to model configuration in > Juju 2.0, separating out things that are not model specific from those > that are. For many things this is very clear-cut, and for other things > not so much. > > For example, api-port and state-port are controller-specific, so we'll > be moving them from model config to a new controller config > collection. The end goal is that you'll no longer see those when you > type "juju get-model-config" (there will be a separate command to get > controller attributes such as these), though we're not quite there yet. > > We also think there are some attributes that people will want to set > across all models, but are not necessarily related to the > *controller*. For example, http-proxy, apt-http-proxy, and their > siblings. I expect that if anyone is setting these particular > attributes, they are doing so for *all* models, as they're operating > within a private cloud with limited network access. > > Does anyone have a real, uncontrived use-case for configuring proxy > settings on a per-model basis? > > Cheers, > Andrew > > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Model config
The danger I think we've tried to avoid with the get/set is that if you have just model-config you can accidentally mutate the state by messing up your arguments you pass in via scripts/etc. It also keeps it consistent across the read/write across the many things that can change now, applications, models, controller, etc. On Wed, Jun 8, 2016 at 9:02 AM Mark Shuttleworth wrote: > > juju set-model-defaults > juju set-model-config > juju set-controller-config > > Have we a strong preference for get/set names, or could we just use > "model-config" and "model-defaults" as read/write commands? > > > Mark > > > On 08/06/16 18:41, Andrew Wilkins wrote: > > Hi folks, > > We're in the midst of making some changes to model configuration in Juju > 2.0, separating out things that are not model specific from those that are. > For > many things this is very clear-cut, and for other things not so much. > > For example, api-port and state-port are controller-specific, so we'll be > moving them from model config to a new controller config collection. The > end goal is that you'll no longer see those when you type "juju > get-model-config" (there will be a separate command to get controller > attributes such as these), though we're not quite there yet. > > We also think there are some attributes that people will want to set > across all models, but are not necessarily related to the *controller*. For > example, http-proxy, apt-http-proxy, and their siblings. I expect that if > anyone is setting these particular attributes, they are doing so for *all* > models, as they're operating within a private cloud with limited network > access. > > Does anyone have a real, uncontrived use-case for configuring proxy > settings on a per-model basis? > > Cheers, > Andrew > > > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Model config
On 08/06/16 22:05, Rick Harding wrote: > The danger I think we've tried to avoid with the get/set is that if > you have just model-config you can accidentally mutate the state by > messing up your arguments you pass in via scripts/etc. It also keeps > it consistent across the read/write across the many things that can > change now, applications, models, controller, etc. > I guess it also allows permission checks to happen once up front and not in the middle of command processing. Mark -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Model config
On 8 June 2016 at 10:41, Andrew Wilkins wrote: > Hi folks, > > We're in the midst of making some changes to model configuration in Juju > 2.0, separating out things that are not model specific from those that are. > For many things this is very clear-cut, and for other things not so much. > > For example, api-port and state-port are controller-specific, so we'll be > moving them from model config to a new controller config collection. The end > goal is that you'll no longer see those when you type "juju > get-model-config" (there will be a separate command to get controller > attributes such as these), though we're not quite there yet. Interesting - seems like a good change. Will this change the internal and API representations too, so there are two groups of mutually-exclusive attributes? Does this also mean that the really-not-very-nice ConfigSkeleton API method will go too? cheers, rog. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Model config
On 08/06/16 23:59, roger peppe wrote: > On 8 June 2016 at 10:41, Andrew Wilkins wrote: >> Hi folks, >> >> We're in the midst of making some changes to model configuration in Juju >> 2.0, separating out things that are not model specific from those that are. >> For many things this is very clear-cut, and for other things not so much. >> >> For example, api-port and state-port are controller-specific, so we'll be >> moving them from model config to a new controller config collection. The end >> goal is that you'll no longer see those when you type "juju >> get-model-config" (there will be a separate command to get controller >> attributes such as these), though we're not quite there yet. > > Interesting - seems like a good change. > > Will this change the internal and API representations too, so there > are two groups > of mutually-exclusive attributes? Does this also mean that the Internally there will be three groups of mutually exclusive attributes: - controller - cloud - model Initially, we'll maintain internal API compatibility by combining all these to produce the result of state.ModelConfig() We'll then be able to consider things like config inheritance / overrides etc. eg if cloud config (specified in the clouds.yaml file) defines an apt-mirror, should we allow a model to also have that value, which will take precedence over the cloud value. > really-not-very-nice > ConfigSkeleton API method will go too? > I hope so. But we're rushing to get everything done for beta9 and are focusing first on the data model since it will be harder to upgrade if that's not right first up. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Model config
On Wed, Jun 8, 2016 at 9:01 PM Mark Shuttleworth wrote: > > juju set-model-defaults > I was mostly wondering whether we should have model defaults, or things that that we'd set at a common level *without* the ability to set on a per-model basis to keep things compartmentalised. Once cloud/region/endpoint and credential attributes are separated from model config, there aren't *that* many things that make sense to have common across models. Anyway, based on Nicolas's response and other discussions the dev team has had internally, we'll go ahead with defaults with the ability to override. Thanks, Andrew > juju set-model-config > juju set-controller-config > > Have we a strong preference for get/set names, or could we just use > "model-config" and "model-defaults" as read/write commands? > > > Mark > > > On 08/06/16 18:41, Andrew Wilkins wrote: > > Hi folks, > > We're in the midst of making some changes to model configuration in Juju > 2.0, separating out things that are not model specific from those that are. > For > many things this is very clear-cut, and for other things not so much. > > For example, api-port and state-port are controller-specific, so we'll be > moving them from model config to a new controller config collection. The > end goal is that you'll no longer see those when you type "juju > get-model-config" (there will be a separate command to get controller > attributes such as these), though we're not quite there yet. > > We also think there are some attributes that people will want to set > across all models, but are not necessarily related to the *controller*. For > example, http-proxy, apt-http-proxy, and their siblings. I expect that if > anyone is setting these particular attributes, they are doing so for *all* > models, as they're operating within a private cloud with limited network > access. > > Does anyone have a real, uncontrived use-case for configuring proxy > settings on a per-model basis? > > Cheers, > Andrew > > > > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Model config
On 09/06/16 11:35, Andrew Wilkins wrote: > On Wed, Jun 8, 2016 at 9:01 PM Mark Shuttleworth <mailto:m...@ubuntu.com>> wrote: > > > juju set-model-defaults > > > I was mostly wondering whether we should have model defaults, or > things that that we'd set at a common level *without* the ability to > set on a per-model basis to keep things compartmentalised. Once > cloud/region/endpoint and credential attributes are separated from > model config, there aren't *that* many things that make sense to have > common across models. > I think there are some things that would be set globally and not per-model, and those would be controller properties. There are other things where it's good to have defaults for every model, but still override per model if you want. Mark -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Specify an existing security group as model config?
Hi all, Since Juju creates a security group per model (and applies it to all instances in that model) it makes it really easy to enable/disable features for all applications in a single model. One such feature is AWS EFS (NFS aaS) which just needs to know which Security Groups can mount that EFS endpoint. There's a problem, however, when tearing down and standing up lots of models in a months time. EFS only allows 5 Security Groups. So if you wanted more than five Kubernetes clusters to access a single mount you need to start editing all the AWS instances to share that Security Group manually. When it comes to scaling operations this can be tedious. I know there are configurations for VPC-ID - is there also a similar security-group setting where either the default model SG will be set based on user input instead of created or a setting where an additional "model" security group can be set so instances have it in addition to the model/instance security group? Thanks, Marco Ceppi -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Specify an existing security group as model config?
On 12/22/2017 03:03 AM, Marco Ceppi wrote: > When it comes to scaling operations this can be tedious. I know there > are configurations for VPC-ID - is there also a similar security-group > setting where either the default model SG will be set based on user > input instead of created or a setting where an additional "model" > security group can be set so instances have it in addition to the > model/instance security group? I think it makes sense that the model creation process might accept such a parameter, yes. Does a security group per model make sense, or should it be per application in the model (though that sounds like it might be wasteful). Mark -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Specify an existing security group as model config?
two cents, typical real world requirements vary, in the enterprise you might have various tiering by architectural layer (front end waf elb ingress, waf servers, set of dmz components/web servers, set of app servers, set of dbs) all structured out with connectivity models. typically these map to a m:n on security group basis to service model, based on the model's responsibilities and consumers. On Fri, Jan 12, 2018 at 8:09 AM, Mark Shuttleworth wrote: > On 12/22/2017 03:03 AM, Marco Ceppi wrote: > > When it comes to scaling operations this can be tedious. I know there > > are configurations for VPC-ID - is there also a similar security-group > > setting where either the default model SG will be set based on user > > input instead of created or a setting where an additional "model" > > security group can be set so instances have it in addition to the > > model/instance security group? > > I think it makes sense that the model creation process might accept such > a parameter, yes. > > Does a security group per model make sense, or should it be per > application in the model (though that sounds like it might be wasteful). > > Mark > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Specify an existing security group as model config?
Marco, we have done a POC of this in the past as a model constraint. So, juju bootstrap aws aws --constraints security-groups=sg1,sg2 juju set-model-constraints security-groups=sg1,sg2,... How does that feel? Nicholas On Sat, Jan 13, 2018 at 1:08 AM, Kapil Thangavelu wrote: > two cents, typical real world requirements vary, in the enterprise you > might have various tiering by architectural layer (front end waf elb > ingress, waf servers, set of dmz components/web servers, set of app > servers, set of dbs) all structured out with connectivity models. typically > these map to a m:n on security group basis to service model, based on the > model's responsibilities and consumers. > > On Fri, Jan 12, 2018 at 8:09 AM, Mark Shuttleworth > wrote: > >> On 12/22/2017 03:03 AM, Marco Ceppi wrote: >> > When it comes to scaling operations this can be tedious. I know there >> > are configurations for VPC-ID - is there also a similar security-group >> > setting where either the default model SG will be set based on user >> > input instead of created or a setting where an additional "model" >> > security group can be set so instances have it in addition to the >> > model/instance security group? >> >> I think it makes sense that the model creation process might accept such >> a parameter, yes. >> >> Does a security group per model make sense, or should it be per >> application in the model (though that sounds like it might be wasteful). >> >> Mark >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/juju >> > > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju > > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Specify an existing security group as model config?
This would be a good start, but this will likely end up being an application level constraint. Marco On Wed, Jan 17, 2018, 13:56 Nicholas Skaggs wrote: > Marco, we have done a POC of this in the past as a model constraint. So, > > juju bootstrap aws aws --constraints security-groups=sg1,sg2 > juju set-model-constraints security-groups=sg1,sg2,... > > How does that feel? > > Nicholas > > On Sat, Jan 13, 2018 at 1:08 AM, Kapil Thangavelu > wrote: > >> two cents, typical real world requirements vary, in the enterprise you >> might have various tiering by architectural layer (front end waf elb >> ingress, waf servers, set of dmz components/web servers, set of app >> servers, set of dbs) all structured out with connectivity models. typically >> these map to a m:n on security group basis to service model, based on the >> model's responsibilities and consumers. >> >> On Fri, Jan 12, 2018 at 8:09 AM, Mark Shuttleworth >> wrote: >> >>> On 12/22/2017 03:03 AM, Marco Ceppi wrote: >>> > When it comes to scaling operations this can be tedious. I know there >>> > are configurations for VPC-ID - is there also a similar security-group >>> > setting where either the default model SG will be set based on user >>> > input instead of created or a setting where an additional "model" >>> > security group can be set so instances have it in addition to the >>> > model/instance security group? >>> >>> I think it makes sense that the model creation process might accept such >>> a parameter, yes. >>> >>> Does a security group per model make sense, or should it be per >>> application in the model (though that sounds like it might be wasteful). >>> >>> Mark >>> >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >> >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> >> > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
