Bootstrap Constraints

[James Beedy]

Rick,

Let me try and detail in short what I'm implementing for networking on aws.

Problem: Multiple 3rd party/vendors need access to application environments
and infrastructure. Network address space not segregated correctly - no way
to separate bootstrap controller from app env subnets/spaces.

    * Developers from other companies need access to different application
environments, I don't want them around my juju controllers (I want to at
least have the capability to create port based security between my
application/model address spaces and the address space where my controllers
go). This would require the ability to be able to place the initial
controller created on bootstrap.

    * I have a set of apps, for each app there exists multiple envs (e.g.
dev, staging, qa, prod). Each app-env has a set of subnets that span the
availability zones in the region, and each of the subnets belong to the
space that belongs to the juju model for the respective application
environment. This should be true for controllers too.

What @dimiter suggests seems like it would be a good solution, because we
can already provide constraints when enabling controller HA (pretty sure
because we can pass constraints there), we just need the capability to
place the first controller on bootstrap.

Thoughts?



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

> 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>
> <http://172.31.5.0/24%60> (with
> or without --config vpc-id=vpc-xyz) to achieve what you want.
>
> Thoughts?
>
> Cheers,
> Dimiter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20161030/110da9ca/attachment.html>