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
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
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
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
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'
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-
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
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
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
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
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
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
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
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-
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/
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
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,
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
>
, 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
20 matches
Mail list logo