juju not respecting spaces constraint

[james beedy]

I have added a space to my model. I am trying to deploy some charms to the space. I have added constraints to the charms in my bundle that constrain them to the space and add root-disk=20G.

The root-disk constraint seems to be applied, but the spaces constraint doesn't stick.

juju spaces https://paste.ubuntu.com/p/MkQCmPqMXV/

bundle.yaml https://paste.ubuntu.com/p/fvxJkkTknk/

juju status https://paste.ubuntu.com/p/W8FpRjmrXR/

juju run --all "ip a | grep 'ens\|eth'" https://paste.ubuntu.com/p/FtsBKN23f3/

You can see from the attached screen shot that the NAT_COMMON_* subnets have the addresses that match the subnets that are in my space, and from the output of the juju run command that the ip addresses of the machines in my model aren't in the space I have constrained them to.

It might be worth adding that this is the first time I have used spaces in aws with juju > 2.7.6. Using spaces in this same way works as expected when I use the jaas controller which is < 2.8.

This can be replicated by adding a space to an aws model running juju > 2.8 and deploying a charm to the space using juju add-space myspace <subnet1> <subnet2> <subnet3> && juju deploy ubuntu --constraints spaces=myspace.

The expected result is that the charm doesn't land in a subnet that is mapped to the space.

[james beedy (jamesbeedy)]

I think I found some further helpful information https://paste.ubuntu.com/p/R8Q9RjPxy3/

As you can see above, juju respects the spaces constraint when I `juju add-machine`, but not when I `juju deploy`.

[John A Meinel (jameinel)]

As mentioned in https://discourse.juju.is/t/aws-spaces-in-2-8/3417
Juju 2.8 got updated so that bindings on an application get properly passed through to the underlying machine as space constraints.

However, it seems that in doing that change we broke passing the application space constraints along with the bindings as spaces that the machine needs. (It is the set of all bindings + all space constraints that determine the machine provisioning.)

While there is a workaround, I would certainly consider this to be a regression.

[Joseph Phillips (manadart)]

https://github.com/juju/juju/pull/11886

[james beedy (jamesbeedy)]

@manadart I have found another bit that may be helpful here

juju bootstrap aws --credential mycred --to subnet=subnet-02bc060304e2d7916

Considering the above command, the controller doesn't end up in the desired subnet.

Possibly you have already picked this up as part of the work you have going on, thought it was worth noting anyway.