Upgrading to VPC on AWS

Andrew Wilkins andrew.wilkins at canonical.com
Mon Oct 10 00:51:21 UTC 2016


On Fri, Oct 7, 2016 at 11:31 PM Mark Shuttleworth <mark at ubuntu.com> wrote:

> Hi folks
>
>
>
> My AWS account pre-dates VPCs, so I didn't have one by default. I've now
>
> added one, how can I update my credential / controller to make use of it
>
> by default?
>

At the moment the only way to use a non-default VPC is to specify it
explicitly when bootstrapping or adding a model, using "--config
vpc-id=vpc-xyz". There are some requirements for the VPC, which bootstrap
will inform you of if they are not met. The error message is pasted below.
A couple of additional things I found while trying it out just now:
 - you should have a subnet for each availability zone
 - to create "default route", set the destination as 0.0.0.0/0. Your routes
should look like:
Destination
Target
Status
Propagated
10.0.0.0/16
local
Active
No
0.0.0.0/0
igw-5bd2103c
<https://console.aws.amazon.com/vpc/home?region=us-east-1#igws:filter=igw-5bd2103c>
Active
No

We'll be making this all automatic. If it can, Juju will create a suitable
VPC, subnets, etc. for you to use, and then use it without you having to
specify any config.

Cheers,
Andrew

"""
The given vpc-id does not meet one or more of the following minimum
Juju requirements:

1. VPC should be in "available" state and contain one or more subnets.
2. An Internet Gateway (IGW) should be attached to the VPC.
3. The main route table of the VPC should have both a default route
   to the attached IGW and a local route matching the VPC CIDR block.
4. At least one of the VPC subnets should have MapPublicIPOnLaunch
   attribute enabled (i.e. at least one subnet needs to be 'public').
5. All subnets should be implicitly associated to the VPC main route
   table, rather than explicitly to per-subnet route tables.

A default VPC already satisfies all of the requirements above. If you
still want to use the VPC, try running 'juju bootstrap' again with:

  --config vpc-id=%s --config vpc-id-force=true

to force Juju to bypass the requirements check (NOT recommended unless
you understand the implications: most importantly, not being able to
access the Juju controller, likely causing bootstrap to fail, or trying
to deploy exposed workloads on instances started in private or isolated
subnets).
"""


> Mark
>
>
>
>
>
> --
>
> Juju mailing list
>
> Juju at lists.ubuntu.com
>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20161010/961d99f2/attachment.html>


More information about the Juju mailing list