juju does not properly prioritize constraints in a v4 bundle
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
Low
|
Unassigned | ||
MAAS |
Invalid
|
Medium
|
Unassigned |
Bug Description
Scenario: 9 'compute' tags, 3 'storage' tags, 3 'neutron' tags (see a picture attached).
Out of 9 nodes with 'compute' tags, 3 nodes are with the 'neutron' tag (mixed). All nodes with the 'storage' tag do not contain any other tags.
One of the machines that should have contained a neutron tag is missing: juju picked one of the 'mixed' neutron-compute nodes for a purely compute node. This is reproducible and is not a one-time thing.
juju show-machine 2
...
current: provisioning error
message: 'cannot run instances: cannot run instance: No available machine matches
(''zone'', [''default''])] (resolved to "interfaces=
...
This is a v4 bundle (https:/
machines:
0:
constraints: "tags=neutron"
1:
constraints: "tags=neutron"
2:
constraints: "tags=neutron"
3:
constraints: "tags=compute"
4:
constraints: "tags=compute"
5:
constraints: "tags=compute"
6:
constraints: "tags=storage"
7:
constraints: "tags=storage"
8:
constraints: "tags=storage"
services:
...
Seems like Juju does not perform the necessary calculations to avoid such a situation.
I realize that there may be conflicts in tag prioritization (picking one or the other leads to an error either way) so there would have to be a conflict resolution mechanism defined.
Currently, it is totally undocumented (correct me if I am wrong), which allocation priorities exist. I can, of course, delete compute tags on neutron nodes but I would rather not.
Specifying tags=usetag,
Versions:
dmitriis@
Desired=
| Status=
|/ Err?=(none)
||/ Name Version Architecture Description
+++-===
ii maas 2.2.0~rc2+
ii maas-cli 2.2.0~rc2+
un maas-cluster-
ii maas-common 2.2.0~rc2+
ii maas-dhcp 2.2.0~rc2+
ii maas-dns 2.2.0~rc2+
ii maas-proxy 2.2.0~rc2+
ii maas-rack-
ii maas-region-api 2.2.0~rc2+
ii maas-region-
un maas-region-
dmitriis@
2.2-beta2-
tags: | added: bundles cpe |
Changed in juju: | |
status: | Incomplete → Triaged |
Changed in maas: | |
status: | New → Incomplete |
status: | Incomplete → Triaged |
importance: | Undecided → Low |
milestone: | none → 2.3.0 |
importance: | Low → Medium |
tags: | added: internal |
Changed in maas: | |
milestone: | 2.3.0 → 2.3.x |
tags: | added: cpe-onsite |
Juju itself does not determine what machines will use what tags or do any prioritization based on it. We simply hand the information off to MaaS to provide us with machines based on the constraints that a user passed in.
I think it is fair that if you see a request for "foo" and you have some machines with "foo" and some with "foo" and "bar", that it might be possible to give preference for the machines that only have "foo" tag. I'm not sure if this is taking it too far.
I think you're reading a *lot* of user intended semantics into tags, when really it is just a list of fields that apply to specific machines.
It may also be a factor that you're creating a bundle and assuming it is going to exactly match the hardware you have available. And we suffer a bit because
a) MAAS does the actual mapping of requested machine characteristics (like tags) to what machine to use
b) Juju only requests the machines one at a time, so there isn't anywhere that can do a "ok, you're going to need 3 of these, and 2 of these, so lets makes sure not to use X so that it is available for Y".
eg, Juju knows the set that you're asking for, but doesn't do the mapping, and only asks MAAS for them one-by-one so it can't work out the set.
That said, if you have machines which *must be used for neutron* then why are you also marking those nodes as possible nodes for "compute"?