Hello,

Is this still confirmed in 2.2? It's really an annoying issue, I have to
manually step every deploy out of bundles, and we're starting to productize
PoCs for k8s, which will heavily rely on this.

Thanks,
Best,
Sam


--
Samuel Cozannet
Cloud, Big Data and IoT Strategy Team
Business Development - Cloud and ISV Ecosystem
Changing the Future of Cloud
Ubuntu <http://ubuntu.com>  / Canonical UK LTD <http://canonical.com> / Juju
<https://jujucharms.com>
<email address hidden>
mob: +33 616 702 389
skype: samnco
Twitter: @SaMnCo_23
[image: View Samuel Cozannet's profile on LinkedIn]
<https://es.linkedin.com/in/scozannet>

On Fri, Feb 24, 2017 at 12:25 PM, Anastasia <<email address hidden>
> wrote:

> Re-triaging to 2.2 :)
>
> ** Changed in: juju
>     Milestone: 2.3.0 => 2.2.0
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1659639
>
> Title:
>   spaces and subnet constraints do not work on AWS with bundles
>
> Status in juju:
>   Triaged
>
> Bug description:
>   Context:
>
>   * Deploying in AWS in a VPC that has 2 public subnets, 2 private
>   subnets
>
>   Sequence:
>   juju bootstrap \
>         --config "vpc-id=vpc-56416e32" \
>         --constraints "instance-type=m3.medium root-disk=128G" \
>         --bootstrap-series=xenial \
>         --credential default \
>         --config vpc-id-force=true \
>         aws/eu-west-1 \
>         k8s-aws
>   juju add-space public
>   added space "public" with no subnets
>   juju add-space private
>   added space "private" with no subnets
>   juju add-subnet subnet-ca4f7cbc private
>   added subnet with ProviderId "subnet-ca4f7cbc" in space "private"
>   juju add-subnet subnet-8fb68aeb private
>   added subnet with ProviderId "subnet-8fb68aeb" in space "private"
>   juju add-subnet subnet-c56d5eb3 public
>   added subnet with ProviderId "subnet-c56d5eb3" in space "public"
>   juju add-subnet subnet-9cd2eef8 public
>   added subnet with ProviderId "subnet-9cd2eef8" in space "public"
>
>   Using bundle:
>
>   series: xenial
>   services:
>     easyrsa:
>        charm: cs:~containers/easyrsa-6
>       num_units: 1
>       contraints: "instance-type=t2.medium spaces=private"
>     etcd:
>       charm: cs:~containers/etcd-23
>       num_units: 3
>       contraints: "instance-type=m3.medium spaces=private"
>     flannel:
>       charm: cs:~containers/flannel-10
>     kubeapi-load-balancer:
>       charm: cs:~containers/kubeapi-load-balancer-6
>       expose: true
>       num_units: 1
>       contraints: "instance-type=t2.medium spaces=public"
>     kubernetes-master:
>       charm: cs:~containers/kubernetes-master-11
>       num_units: 1
>       contraints: "instance-type=m3.medium spaces=private"
>     kubernetes-worker:
>       charm: cs:~containers/kubernetes-worker-13
>       expose: true
>       num_units: 3
>       contraints: "instance-type=m4.large root-disk=64G spaces=public"
>
>   (removed unecessary stuff)
>
>   Output:
>
>   juju status --color
>   ...
>
>   Unit                      Workload  Agent  Machine  Public address
> Ports           Message
>   easyrsa/0*                active    idle   0        10.0.251.199
>             Certificate Authority connected.
>   etcd/0*                   active    idle   1        10.0.252.10
>  2379/tcp        Healthy with 3 known peers.
>   etcd/1                    active    idle   2        10.0.251.202
> 2379/tcp        Healthy with 3 known peers.
>   etcd/2                    active    idle   3        10.0.251.164
> 2379/tcp        Healthy with 3 known peers.
>   kubeapi-load-balancer/0*  active    idle   4        34.248.132.128
> 443/tcp         Loadbalancer ready.
>   kubernetes-master/0*      active    idle   5        10.0.251.41
>  6443/tcp        Kubernetes master running.
>     flannel/0*              active    idle            10.0.251.41
>            Flannel subnet 10.1.103.1/24
>   kubernetes-worker/0*      active    idle   6        10.0.252.198
> 80/tcp,443/tcp  Kubernetes worker running.
>     flannel/1               active    idle            10.0.252.198
>             Flannel subnet 10.1.72.1/24
>   kubernetes-worker/1       active    idle   7        34.249.72.81
> 80/tcp,443/tcp  Kubernetes worker running.
>     flannel/2               active    idle            34.249.72.81
>             Flannel subnet 10.1.93.1/24
>   kubernetes-worker/2       active    idle   8        10.0.251.46
>  80/tcp,443/tcp  Kubernetes worker running.
>     flannel/3               active    idle            10.0.251.46
>            Flannel subnet 10.1.29.1/24
>
>   Machine  State    DNS             Inst id              Series  AZ
>   0        started  10.0.251.199    i-0a04399664027aac4  xenial  eu-west-1a
>   1        started  10.0.252.10     i-0cf6b3b1c445702fb  xenial  eu-west-1b
>   2        started  10.0.251.202    i-0d73bc0747307383f  xenial  eu-west-1a
>   3        started  10.0.251.164    i-03260cd5bfca2ec36  xenial  eu-west-1a
>   4        started  34.248.132.128  i-02900c2dac8cebd70  xenial  eu-west-1b
>   5        started  10.0.251.41     i-00daea7e56b303982  xenial  eu-west-1a
>   6        started  10.0.252.198    i-0f4dcd06804f1260b  xenial  eu-west-1b
>   7        started  34.249.72.81    i-0f20a12712404c4bc  xenial  eu-west-1a
>   8        started  10.0.251.46     i-0d556ffdaaf7a3e27  xenial  eu-west-1a
>
>   So machines 6 to 8 should be in public and only one of them is. Also,
>   all machines deployed with m3.medium and did not respect the
>   constraints
>
>   Adding units has the same consequences, they get allocated to random
>   subnets.
>
>   Expected behavior:
>   * Units are assigned to the proper subnet(s) in the proper space.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1659639/+subscriptions
>