juju not respecting "spaces" constraints

Bug #2031891 reported by Junien F
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical Juju
Fix Released
High
Nicolas Vinuesa

Bug Description

Hi,

juju doesn't seem to respect spaces constraints.

$ juju version
3.1.2-ubuntu-amd64

$ juju spaces
Name Space ID Subnets
alpha 0 10.142.23.0/24
                   252.0.0.0/8
edge 1 2620:XXX::/64
                   91.XXX.0/25
storage 2 10.140.60.0/23

$ juju deploy --base ubuntu@22.04 ch:ubuntu-mirror --constraints spaces=alpha,^edge,^storage test1

$ openstack server list|grep juju
| d471a14d-801c-40c2-aeba-88427cafb2b1 | juju-e490b0-stg-moon127-7 | ACTIVE | net_edge=2620:XXX::113, 91.XXX.98; net_stg-moon127=10.142.23.132; net_tenant-storage=10.140.61.73 | N/A (booted from volume) | staging-cpu2-ram4-disk20 |

I'd expect the created VM to only be on "net_stg-moon127"

Thanks !

Revision history for this message
Ian Booth (wallyworld) wrote :

Do you happen to know if this is a regression from 2.9? Did it only break for you in 3.1.x?

Changed in juju:
milestone: none → 3.1.6
status: New → Triaged
importance: Undecided → High
Revision history for this message
Junien F (axino) wrote :

Hi Ian - I'm afraid I don't know if it's a regression or not. I only tested this on this controller. Our openstack tenants generally only have access to a single subnet, so we very rarely run into this scenario.

Changed in juju:
milestone: 3.1.6 → 3.1.7
Changed in juju:
milestone: 3.1.7 → none
assignee: nobody → Nicolas Vinuesa (nvinuesa)
Changed in juju:
milestone: none → 3.3.4
Changed in juju:
milestone: 3.3.4 → 3.3.5
Changed in juju:
milestone: 3.3.5 → 3.3.6
Changed in juju:
milestone: 3.3.6 → 3.4.4
Changed in juju:
status: Triaged → In Progress
Revision history for this message
Nicolas Vinuesa (nvinuesa) wrote :

Hi Junien (and I'm very sorry for this very late reply on the bug). So I managed to reproduce and find the reason why you are seeing this behavior.

According to the constraints you passed, you have all spaces as negative except alpha, and we have a condition on which if alpha is the only space to include then we don't perform any space topology (thus letting the openstack provider create one port per known network). This is your case and therefore you see that the server that has been deployed has the three ports one per network. This is the condition:
https://github.com/juju/juju/blob/3.4/apiserver/facades/agent/provisioner/provisioninginfo.go#L346-L351

If you do `juju deploy --base ubuntu@22.04 ch:ubuntu-mirror --constraints spaces=alpha,edge,^storage test1`
you will see that indeed the negative constraint works and the server will only be on net_edge and net_stg.

IMO the issue here is that we had this condition for the cases where the user doesn't provide any space constraints and therefore the default space list was [alpha]. Maybe we should review this and have a different case when the user explicitly passes alpha as the only space.

Revision history for this message
Nicolas Vinuesa (nvinuesa) wrote :
Changed in juju:
status: In Progress → Fix Committed
Changed in juju:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.