can't deploy to specific AWS subnets due to `juju add-subnet` fails

[Eric]

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/

[Anastasia (anastasia-macmood)]

@Eric,

I think the syntax that worked for me was to specify subnets when creating space, something along the lines of 'juju add-space foo 172.30.4.0/24'

[Eric (eric-galacticfog)]

Hi Anastasia,

Thanks, the command seems to succeed. I will try to deploy with
constraints and report back.

Is there a way to alter or remove a space after it's created? (either by
juju command or otherwise)

On Mon, Jul 17, 2017 at 5:29 PM, Anastasia <email address hidden>
wrote:

> @Eric,
>
> I think the syntax that worked for me was to specify subnets when
> creating space, something along the lines of 'juju add-space foo
> 172.30.4.0/24'
>
> --
> 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>
[phone]

[Anastasia (anastasia-macmood)]

@Eric,
I do not think so :) AFAIK, it's on the list of things to do...

[Eric (eric-galacticfog)]

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>
[phone]

[Anastasia (anastasia-macmood)]

Triaging as High as we really need to address spaces and subnets CLI.

Thank you for reporting.

[Shibo (obviouslygreen)]

Any update on this? Should at least have a note in the documentation that this isn't working or not have it at all (https://jujucharms.com/docs/2.3/network-spaces).

Would save lots of time for everyone :)

Thanks,

Shibo

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.