rp- opened a new pull request, #13998:
URL: https://github.com/apache/cloudstack/pull/13998
### Description
This PR fixes deploying a VM on LINSTOR primary storage with a root disk
larger than its template
when the LINSTOR resource group has `Clone/BalanceAfterClone=true`.
The plugin created such a volume as: clone the template resource-definition,
wait for the clone
to report COMPLETE, then `volumeDefinitionModify` to the requested size.
LINSTOR reports a clone
COMPLETE as soon as every replica can access UpToDate data - with
BalanceAfterClone that is
while the additional balance replica is still syncing - and the resize is
rejected because it
requires all diskful replicas to be UpToDate:
```
Linstor: ApiEx - [{"ret_code":-4611686018390686770,
"message":"Cannot resize volume, because we have a non-UpToDate DRBD
device.", ...}]
```
The deploy then fails with a bare `errorcode 530 Unable to orchestrate the
start of VM instance`
and the instance is left in Error state. Waiting client-side is not an
option, it would block the
deploy for the whole initial sync of the template size.
LINSTOR 1.35.0 (REST API 1.29.1) accepts `volume_sizes` on the clone request
and grows the
cloned volume inside the clone, before the balance placement. The plugin now
checks the
controller's REST API version, passes the size in the clone request on >=
1.29.1 and skips the
post-clone resize; older controllers keep the previous clone-then-resize
sequence unchanged.
java-linstor is updated to 0.8.1 for the new request field;
`resourceSnapshotDelete` gained an
optional `delete_empty_resource_definition` parameter which is passed as
`null`.
Also includes a small marvin fix: `test_07_detach_volume_reboot_vm` used the
bare `reboot()`
instead of the `_reboot_vm` helper that waits for the guest, which made
`test_08` detach a volume
from a guest that had not enumerated it yet when a fast-booting template is
used.
<!--- Describe your changes in DETAIL - And how has behaviour functionally
changed. -->
<!-- For new features, provide link to FS, dev ML discussion etc. -->
<!-- In case of bug fix, the expected and actual behaviours, steps to
reproduce. -->
<!-- When "Fixes: #<id>" is specified, the issue/PR will automatically be
closed when this PR gets merged -->
<!-- For addressing multiple issues/PRs, use multiple "Fixes: #<id>" -->
<!-- Fixes: # -->
<!---
*******************************************************************************
-->
<!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE
DOCUMENTATION. -->
<!--- PLEASE PUT AN 'X' in only **ONE** box -->
<!---
*******************************************************************************
-->
### Types of changes
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] New feature (non-breaking change which adds functionality)
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] Enhancement (improves an existing feature and functionality)
- [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
- [ ] Build/CI
- [ ] Test (unit or integration test code)
### Feature/Enhancement Scale or Bug Severity
#### Feature/Enhancement Scale
- [ ] Major
- [ ] Minor
#### Bug Severity
- [ ] BLOCKER
- [ ] Critical
- [x] Major
- [ ] Minor
- [ ] Trivial
### Screenshots (if appropriate):
### How Has This Been Tested?
Unit tests for the version comparison, the version probe and the clone-size
decision
(`LinstorUtilTest`, `LinstorPrimaryDataStoreDriverImplTest`).
3-node KVM cluster, LINSTOR primary storage (LVM-thin, place-count 2):
- LINSTOR 1.34.2 (REST API 1.29.0): `test_linstor_volumes.py` and
`test_linstor_encrypted_snapshots.py`
pass (18/18), the log shows the unchanged clone-then-resize sequence.
- LINSTOR 1.35.0 (REST API 1.29.1) with `Clone/BalanceAfterClone=true` on
the resource group:
deploying VMs with `rootdisksize` larger than the template (512 MiB
template, 12/16/20 GiB
root disks, several in parallel) succeeds every time. No resize call in
the log, the
volume-definition has the requested size and the balance replica is still
SyncTarget while the
VM is already running - the state in which the previous code failed.
Before the fix, on the same cluster with `Clone/BalanceAfterClone=true`, 9/9
such deploys failed
with the error above.
<!-- Please describe in detail how you tested your changes. -->
<!-- Include details of your testing environment, and the tests you ran to
-->
#### How did you try to break this feature and the system with this change?
- Old controller (1.34.2): fallback path is the previous sequence,
`volume_sizes` is never sent.
- Controller unreachable during the version probe: falls back to
clone-then-resize, the clone
then fails with the controller's error as before.
- Several deploys in parallel while balance replicas were syncing.
- Size equal to the template size (no-op in LINSTOR), smaller sizes are
rejected at clone start
and CloudStack enforces root size >= template size anyway.
- Version strings with two/three components, empty and garbage input.
<!-- see how your change affects other areas of the code, etc. -->
<!-- Please read the
[CONTRIBUTING](https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md)
document -->
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
