Skip to content

adaptive: honor user-provided capacityBytes when provider stats are unavailable#13059

Open
genegr wants to merge 1 commit intoapache:4.20from
genegr:feat/adaptive-lifecycle-honor-user-capacity
Open

adaptive: honor user-provided capacityBytes when provider stats are unavailable#13059
genegr wants to merge 1 commit intoapache:4.20from
genegr:feat/adaptive-lifecycle-honor-user-capacity

Conversation

@genegr
Copy link
Copy Markdown

@genegr genegr commented Apr 22, 2026

Description

Registering an adaptive-plugin-backed managed primary pool currently fails with Capacity bytes not available from the storage provider, user provided capacity bytes must be specified even when capacityBytes= is actually passed to createStoragePool, whenever the provider cannot report capacity at that moment (for example a FlashArray pod with no quota and no footprint yet, or a transient probe failure).

Root cause lives in AdaptiveDataStoreLifeCycleImpl.initialize(): the user-supplied capacity was guarded behind stats != null, so any null stats caused a fall-through to the "no user capacity either" error branch even when the user did provide one.

This change accepts the user-supplied value unconditionally and uses the provider stats only as an upper-bound sanity check when they are actually available. The "no user-provided capacity, no provider capacity" branch is preserved and still raises the same InvalidParameterValueException.

Types of changes

  • Bugfix (non-breaking change which fixes an issue)

Feature/Enhancement Scale or Bug Severity

Major for any deployment that uses the adaptive storage framework against a provider which cannot report capacity synchronously at pool-register time — registration will always fail regardless of what capacityBytes is passed.

How Has This Been Tested?

Validated end-to-end on a 4.23-SNAPSHOT lab:

  • Registered a FlashArray primary pool (provider="Flash Array", transport=nvme-tcp) against an empty Purity pod with capacitybytes=1099511627776 and capacityiops=100000. Before this change, the registration failed with the error above; after this change, the pool enters the Up state using the user-provided capacity.
  • Registered a pool against a pod that does report stats; the pool's capacity comes from the provider as before, and the upper-bound check still rejects a user-supplied capacityBytes that exceeds the provider's capacity.
  • Exercised a 20 GiB volume end-to-end (create, attach to a Rocky 9 VM, mkfs.ext4 + SHA-256 write/verify, live-migrate between two KVM hosts with the data disk attached — no I/O gap across the migrate).

@winterhazel
Copy link
Copy Markdown
Member

@genegr as this is a simple bug fix, could you rebase over branch 4.20 to include it on the next 4.20/4.22 minor versions?

…navailable

AdaptiveDataStoreLifeCycleImpl.initialize() guarded the user-provided
capacityBytes behind stats != null when computing the pool capacity to
persist. As a consequence, any adaptive provider that could not report
capacity yet (for example a FlashArray pod that has not been given a
quota and has no footprint yet, or a transient probe failure) caused the
whole pool registration to fail with "Capacity bytes not available from
the storage provider, user provided capacity bytes must be specified"
even when the operator had passed capacityBytes= on createStoragePool.

Accept the user-supplied value unconditionally and use the provider
stats only as an upper-bound sanity check when they are actually
available. The "no user-provided capacity, no provider capacity" branch
is preserved and still raises the same InvalidParameterValueException.

Signed-off-by: Eugenio Grosso <eugenio.grosso@gmail.com>
@genegr genegr force-pushed the feat/adaptive-lifecycle-honor-user-capacity branch from e7d2553 to 25641c3 Compare April 23, 2026 00:23

if (CollectionUtils.isNotEmpty(quarantinedAddressesIDs)) {
sc.setParameters("id", quarantinedAddressesIDs.toArray());
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@genegr IP related changes are not relevant to the PR description.

@codecov
Copy link
Copy Markdown

codecov Bot commented Apr 23, 2026

Codecov Report

❌ Patch coverage is 0% with 51 lines in your changes missing coverage. Please review.
✅ Project coverage is 18.01%. Comparing base (1fc4cb9) to head (25641c3).
⚠️ Report is 758 commits behind head on main.

Files with missing lines Patch % Lines
...n/java/com/cloud/network/IpAddressManagerImpl.java 0.00% 35 Missing ⚠️
...m/cloud/network/dao/PublicIpQuarantineDaoImpl.java 0.00% 13 Missing ⚠️
...tore/lifecycle/AdaptiveDataStoreLifeCycleImpl.java 0.00% 3 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##               main   #13059      +/-   ##
============================================
+ Coverage     16.27%   18.01%   +1.74%     
- Complexity    13438    16605    +3167     
============================================
  Files          5665     6029     +364     
  Lines        500534   542181   +41647     
  Branches      60789    66451    +5662     
============================================
+ Hits          81437    97663   +16226     
- Misses       409992   433501   +23509     
- Partials       9105    11017    +1912     
Flag Coverage Δ
uitests 3.52% <ø> (-0.64%) ⬇️
unittests 19.17% <0.00%> (+2.04%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@genegr genegr changed the base branch from main to 4.20 April 23, 2026 07:37
@genegr
Copy link
Copy Markdown
Author

genegr commented Apr 23, 2026

Rebased onto apache/cloudstack:4.20 per @winterhazel's request — single commit 25641c3938 adaptive: honor user-provided capacityBytes when provider stats are unavailable.

No content changes; only the base.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants