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@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
