Canonical Juju

Bug #1321442
Comment #15

Comment 15 for bug 1321442

Revision history for this message

Dimiter Naydenov (dimitern) wrote on 2016-04-26:

#15

Some updates on the approach and scope of this fix. Currently Juju just assumes a default VPC exists, even though we still verify if it's there in order to decide whether networking is supported or not. The end goal will be for Juju to allow more complex networking setups on AWS, with a customized VPC and subnets, including support for "private" subnets (where instances start without an automatic public IP and are not accessible from the internet). In order to get there, we first need to ensure we can be explicit about which VPC ID should be used throughout provider/ec2. To provide comparable UX on a non-default VPC juju needs to verify whether the VPC is configured to at least allow access to it from the internet, so juju client can connect to the controller. If that's not true Juju can't really work out-of-the box in this case, as it won't even be able to complete bootstrapping. To ensure VPC can be accessed from the outside, at least one of its subnets route tables (or the main VPC route table) must have an Internet Gateway linked to it. Another requirement obviously is that the VPC has at least one usable subnet. Juju can verify both of these before trying to bootstrap and give a meaningful error message to the user how to rectify the situation.

So the fix I'm working on will allow:
1. with no user-specified vpc-id, detecting the default VPC ID and using it explicitly where needed to make AWS API calls
2. once a vpc-id is chosen at boostrap, it cannot be changed for the lifetime of the model
3. with a user-specified vpc-id (e.g. --config vpc-id=vpc-a1b2c3d4 passed at bootstrap), at minimum validate the following:
3.1. the vpc with that ID exists (for the user - i.e. it might not be visible due to lack of permissions)
3.2. the vpc has an internet gateway attached to it
3.3. the vpc has at least one subnet, which can be accessed from the internet (and use that subnet for the bootstrap node)
4. provide a way for the user to force Juju to use a vpc which otherwise will have failed checks 3.2 or 3.3. above (e.g. --config force-vpc-id ?) Unless forced, juju will error out and refuse to bootstrap

The above should enable a lot more complex VPC networking scenarios, while preserving backwards-compatible UX as much as possible, and allow a power user to configure the VPC how they want. It won't guarantee Juju will work with a non-default VPC *exactly the same way* as with a default VPC, and that perhaps deserves a WARNING during bootstrap.

Some updates on the approach and scope of this fix. Currently Juju just assumes a default VPC exists, even though we still verify if it's there in order to decide whether networking is supported or not. The end goal will be for Juju to allow more complex networking setups on AWS, with a customized VPC and subnets, including support for "private" subnets (where instances start without an automatic public IP and are not accessible from the internet). In order to get there, we first need to ensure we can be explicit about which VPC ID should be used throughout provider/ec2. To provide comparable UX on a non-default VPC juju needs to verify whether the VPC is configured to at least allow access to it from the internet, so juju client can connect to the controller. If that's not true Juju can't really work out-of-the box in this case,  as it won't even be able to complete bootstrapping. To ensure VPC can be accessed from the outside, at least one of its subnets route tables (or the main VPC route table) must have an Internet Gateway linked to it. Another requirement obviously is that the VPC has at least one usable subnet. Juju can verify both of these before trying to bootstrap and give a meaningful error message to the user how to rectify the situation.