Bootstrap Constraints

[Rick Harding]

James, can you provider more detailed info on the rules of your deployment
you're looking for?

You mention wanting a controller away from other things on a subnet? Does
this reach out true for HA nodes on that controller, workloads brought up
by that controller? Are you expecting some sort of subnet affinity for
everything from a controller given it's deployed to a specific subnet? If
so, what's the use case you're driving forward with?

Thanks for the insight to help us better plan what we want to do to enable
different end user situations.

On Sat, Oct 29, 2016 at 7:40 PM James Beedy <jamesbeedy at gmail.com> wrote:

> Dimiter,
>
> Thanks for looking into this. That sounds like an awesome solution!
>
> ~James
>
>
> > Team,
> >
> > From what I can gather, Juju either allows or disallows you to bootstrap
> > to a specific network/subnet dependent on whether or not the provider
> > supports a network space bootstrap constraint. The EC2 provider just so
> > happens to be one of the providers which doesn't support controller
> > placement on bootstrap. This is a massive problem for me, seeing as I
> > have many subnets for things other than controller nodes. I just can't
> > seem to get the controller to land in a subnet (seems to be chosen at
> > some sort of random) that doesn't already have other things in it that I
> > don't want around my controller. To facilitate bootstrap network
> > constraints on the EC2 provider, I think a 'network' constraint is
> > needed, along with some filtering of the provided 'network' constraint
> > value to ensure the subnet exists, is in the current region and current
> > vpc - seems like it might do the trick until we have a flat model for
> > controller placement that works across all providers.
> >
> > Thoughts?
> >
> >
> Hey James,
>
> Sorry for the late reply! The EC2 provider does not support the tags=
> constraint, and it has limited support for the spaces= constraint - but
> not for the controller, as at bootstrap time no spaces are yet defined.
> So unfortunately you can't yet explicitly specify where a controller
> instance will end up on.
>
> To allow explicit placement for EC2 instances, including Juju
> controllers, we could (trivially) implement support for `--to
> subnet=<CIDR>` placement (like the existing - and supported - `--to
> zone=<name>`).
>
> Then you could do `juju bootstrap ... --to subnet=172.31.5.0/24`
> <http://172.31.5.0/24%60> (with
> or without --config vpc-id=vpc-xyz) to achieve what you want.
>
> Thoughts?
>
> Cheers,
> Dimiter
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20161030/0ba40153/attachment.html>