allocate command doesn't respect system_id and name when a pod is registered
Bug #1811836 reported by
Björn Tillenius
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| MAAS |
Triaged
|
Medium
|
Unassigned | ||
Bug Description
This is with MAAS 2.5.1-7489-
I have a normal user and a machine A that is allocated to another user.
There's also a pod registered that has capacity to create new VMs.
If I use the allocate API like this:
maas non-admin machines allocate name=A
I get a machine from the pod. The same happens if I specify the system_id instead.
This is wrong, since the resulting machine doesn't match the constraint I specified.
The machine that you get back has an automatically generated name.
With MAAS 3.3, it seems that passing a non-existing system_id does indeed fail as expected, but passing in a non-existing name still gives you a (virtual) machine.
| Changed in maas: | |
| status: | New → Triaged |
| importance: | Undecided → Medium |
| milestone: | none → 2.5.1 |
| tags: | added: api |
| Changed in maas: | |
| milestone: | 2.5.1 → 2.5.2 |
| Changed in maas: | |
| milestone: | 2.5.2 → 2.5.3 |
| milestone: | 2.5.3 → 2.5.2 |
| Changed in maas: | |
| milestone: | 2.5.2 → 2.5.3 |
| Changed in maas: | |
| milestone: | 2.5.3 → 2.5.4 |
| Changed in maas: | |
| milestone: | 2.5.4 → none |
Revision history for this message
| Jerzy Husakowski (jhusakowski) wrote | #1 |
| Changed in maas: | |
| milestone: | none → 3.4.0 |
| summary: |
- [2.5, API] allocate command doesn't respect system_id and name when a - pod is registered + allocate command doesn't respect system_id and name when a pod is + registered |
| description: | updated |
| Changed in maas: | |
| milestone: | 3.4.0 → 3.4.x |
To post a comment you must log in.
The behaviours of the CLI and API are confusing. MAAS should not guess and should follow constraints. The allocate API should have parameters that identify existing machines, and parameters that constrain composing, and MAAS should have a deterministic way of addressing allocate API requests (e.g. the name is only a matching constraint).
This may require adding a new version of the API as the fix will likely break old behaviour.