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

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:

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

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

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

Re: RFC "bootstrap --config" should be treated as "--model-default" and add "--model-config"

ls on your controller. > > Given '--config' is what people are used to supplying, and is the wording > used in configuration files, it feels natural to use it on the command line > as well. > > I'm not 100% sure whether it should be --model-config to match 'juju > model-config'

Re: RFC "bootstrap --config" should be treated as "--model-default" and add "--model-config"

del-defaults and apply > to all models on your controller. > > Given '--config' is what people are used to supplying, and is the > wording used in configuration files, it feels natural to use it on the > command line as well. > > I'm not 100% sure whether it should be --model-

RFC "bootstrap --config" should be treated as "--model-default" and add "--model-config"

apply to all models on your controller. Given '--config' is what people are used to supplying, and is the wording used in configuration files, it feels natural to use it on the command line as well. I'm not 100% sure whether it should be --model-config to match 'juju model-config' or --boots

Re: Bug 1642609: new model config defaults

On 2016-12-07 03:37 PM, Michael Foord wrote: > I am strongly of the opinion that at the very least a newly created > model should be capable of deploying workloads, which means that at > least a subset of model-config options should be propagated by default > to new models. This me

Re: Bug 1642609: new model config defaults

I created bug 1648426 to track discussion of which model config options should (if indeed any...) propagate by default. https://bugs.launchpad.net/juju/+bug/1648426 Michael On 07/12/16 21:37, Michael Foord wrote: Hey all, I spent far longer than was reasonable working out why OIL were

Bug 1642609: new model config defaults

and deploying bundles into the models. The Xenial machines would provision and trusty machines fail. The cause of the problem is actually by design, although I would argue still insane and needs fixing. The agent-stream (proposed) is a model-config option that is not propagated to new models. So for new

Re: Model config

gs 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

Re: Model config

mpartmentalised. 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 ahea

Re: Model config

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 >> goa

Re: Model config

his 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-

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/

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

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,

Re: Model config

le, 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 >

Model config

, 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