Comment 4 for bug 1704876

Thank you. I've confirmed that in my case, I am able to target specific
subnets. Here are example commands:

```
SUBNET_PUBLIC_CIDR=10.101.1.0/24
SUBNET_PRIVATE_CIDR=10.101.2.0/24

juju add-space public $SUBNET_PUBLIC_CIDR
juju add-space private $SUBNET_PRIVATE_CIDR

juju deploy --constraints "spaces=private" <...>
```

But, it seems that once I run `juju add-space private
$SUBNET_PRIVATE_CIDR`, I can't modify the `private` space anymore. I can't
add more subnets, or delete the space. There appears to be a workaround ..
one can "steal" a subnet from a space by creating a new space:

juju add-space private $SUBNET_PRIVATE_CIDR # First, map the subnet to
space 'private'
juju add-space test $SUBNET_PRIVATE_CIDR # This moves the subnet from
space 'private' to space 'test'

On Tue, Jul 18, 2017 at 12:09 AM, Adam Stokes <email address hidden>
wrote:

> ** Tags added: conjure
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1704876
>
> Title:
> can't deploy to specific AWS subnets due to `juju add-subnet` fails
>
> Status in juju:
> New
>
> Bug description:
> Encountering an issue with `juju add-subnet <space>` when trying to
> associate a VPC's existing subnets with network spaces. This blocks
> the ability to deploy a bundle to an existing VPC and specific
> subnets, which is important for co-existing with existing
> infrastructure.
>
> Appreciate information on a workaround in the meantime (e.g. could a
> subnet be associated with a space by modifying the controller?). The
> intention is to use spaces with deployment constraints (e.g. juju
> deploy --constraints "instance-type=m3.medium spaces=private"
> cs:~containers/etcd-40)
>
> Here are the error details:
>
> ```
> $ juju version
> 2.2.2-xenial-amd64
>
> $ juju add-space private
> added space "private" with no subnets
>
> $ juju add-subnet $SUBNET_ID private
> ERROR cannot add subnet: adding subnet "10.101.1.0/24": subnet "
> 10.101.1.0/24" already exists
>
> ubuntu@ip-10-101-1-137:~$ juju subnets
> subnets:
> 10.101.1.0/24:
> type: ipv4
> provider-id: subnet-xxxxxxx
> status: in-use
> space: ""
> zones:
> - us-east-2b
> ...
> ```
>
> The overall approach to deploying to existing subnets is shown in this
> blog, which references the approach of using spaces -
> https://insights.ubuntu.com/2017/02/08/automate-the-deployment-of-
> kubernetes-in-existing-aws-infrastructure/
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1704876/+subscriptions
>

--

Eric Sonchaiwanich
Field Engineering | Galactic Fog
<email address hidden>
(929) 314-2760