Cannot scale out when network spaces and placement directives are in use

[Peter Matulis]

I deployed an OpenStack cloud on three MAAS nodes with a bundle and overlay (both attached):

$ juju deploy ./bundle.yaml --overlay ./overlay.yaml

Both a network space ('public-space') and placement directives are used.

It gave me a single vault application (hosted on 1/lxd/4), which I then tried to scale out on the other two MAAS nodes:

$ juju add-unit -n 2 --to lxd:0,lxd:2 vault

This didn't work. The `juju status` command output shows:

no obvious space for container "0/lxd/6", host machine has spaces: "admin-space", "ceph-access-space", "ceph-replica-space", "internal-space", "oam-space", "overlay-space", "public-space"

As a workaround, I added two machines with the 'spaces' constraint and then scaled out onto those machines:

$ juju add-machine lxd:0 --constraints spaces=public-space
$ juju add-machine lxd:2 --constraints spaces=public-space
$ juju add-unit -n 2 --to 0/lxd/8,2/lxd/9 vault

[Ian Booth (wallyworld)]

This is interesting. The use of '--to' by passes constraints, but the premise there is that the unit is going to be deployed on an existing machine, so constraints are irrelevant.

However, for placement to a new container, then you could argue that constraints are necessary, not just for spaces but also memory etc.

I wonder if we need to add --constraints to add-unit for the --to lxd option.

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

This Medium-priority bug has not been updated in 60 days, so we're marking it Low importance. If you believe this is incorrect, please update the importance.