[2.3] Unhandled error when invalid storage pod resources, doesn't surface to the UI
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| MAAS |
Undecided
|
Mike Pontillo | ||
| 2.3 |
Undecided
|
Unassigned | ||
| 2.4 |
Undecided
|
Unassigned |
Bug Description
This is a regression issue for:
maas 2.3.3-6498-
maas-cli 2.3.3-6498-
maas-common 2.3.3-6498-
maas-dhcp 2.3.3-6498-
maas-dns 2.3.3-6498-
maas-proxy 2.3.3-6498-
maas-rack-
maas-region-api 2.3.3-6498-
maas-region-
python3-django-maas 2.3.3-6498-
python3-maas-client 2.3.3-6498-
python3-
Composing a new VM on a KVM pod does not allow to overcommit local storage.
The action fails silently on the UI, and in the logs it reports:
==> /var/log/
2018-05-18 14:10:35 twisted.
2018-05-18 14:10:35 twisted.
Traceback (most recent call last):
Failure: provisioningser
description: | updated |
Andres Rodriguez (andreserl) wrote : | #1 |
Changed in maas: | |
status: | New → Incomplete |
milestone: | none → 2.4.1 |
summary: |
- Cannot overcommit storage for KVM pods, silent failure + [2.3] Unhandled error when invalid storage pod resources |
summary: |
- [2.3] Unhandled error when invalid storage pod resources + [2.3] Unhandled error when invalid storage pod resources, doesn't + surface to the UI |
Michael Iatrou (michael.iatrou) wrote : | #2 |
1. Upgraded from 2.3.2.
2. Although on the pod page the "Local storage" information would show "246.8 GiB used -30.4 GiB available", I was able to compose more machines, since the volumes are thin provisioned.
df shows that there is plenty of space available:
/dev/sdb2 217G 133G 83G 62% /
Being able to overcommit storage is super-useful!
I understand that if it's not intentional it can cause issues.
I propose to make it configurable, perhaps on a per pod basis.
Michael Iatrou (michael.iatrou) wrote : | #3 |
Fiddling with the capacity calculation gives me back the previous behavior, but it would be awesome if overcommit for storage was configurable.
https:/
Changed in maas: | |
milestone: | 2.4.1 → 2.4.2 |
Changed in maas: | |
milestone: | 2.4.2 → 2.4.3 |
Changed in maas: | |
assignee: | nobody → Mike Pontillo (mpontillo) |
milestone: | 2.4.3 → 2.5.0 |
milestone: | 2.5.0 → 2.5.0beta1 |
Mike Pontillo (mpontillo) wrote : | #4 |
I'm not entirely clear on what the issue is here. In MAAS 2.5 I see the following if I try to compose a machine with more storage than is available on disk:
Pod unable to compose machine: Not enough space in default storage pool: maas
... and it's surfaced in the UI.
Beyond the feedback that it would be nice to allow storage to be overcommitted, is there behavior here that still needs fixing?
Changed in maas: | |
status: | Incomplete → Invalid |
Mike Pontillo (mpontillo) wrote : | #5 |
Another thought on this: I wonder if the calculations are thrown off if MAAS is using a hypervisor as a pod that has a large number of shared copy-on-write images?
Changed in maas: | |
milestone: | 2.5.0beta1 → 2.5.0beta2 |
Changed in maas: | |
milestone: | 2.5.0beta2 → none |
Hi Michael,
I /believe/ that MAAS wasn't meant to overcommit storage (but it would do for CPU/RAM). As such, the fact that it is no longer possible is an actual bugfix due to issues in the field. That said, could you please let me know:
1. From which version did you upgrade?
2. What was the behavior before you upgraded?