snapshot physical size for the primary storage resource

[PPisz]

Hello,

We are struggling with this issue on CS 4.22 and 4.22.1, is there a chance to implement this fix to 4.22.x?

#12481

Piotr

[DaanHoogland]

$ git tag --contains 83ce0067b82bc39c7c91667c6ac4d2dd144ce450
4.20.3.0
4.22.1.0

That is the merge commit for #12481. So you are saying the PR doesn’t fix this (on 4.22.1.0)?

[PPisz]

Thanks for the pointer. I've checked and the commit is indeed in 4.22.1.0 and 4.20.3.0, and we are on 4.22.1.0 right now (apt-cache policy cloudstack-management → Installed: 4.22.1.0).

However, PR #12481 (per its title "Update the snapshot physical size for the primary storage resource after snapshot creation and during resource count recalculation") and its parent issue #11441 ("Snapshot Size Not Counted in Primary Storage Quota") fix a resource-count / quota bug — i.e. how cloud.resource_count tracks snapshot sizes against primary-storage quota. Files touched are ResourceLimitManagerImpl.java, SnapshotDataStoreDao(Impl).java, SnapshotManagerImpl.java, etc.

The bug we're hitting is in a different subsystem: the Usage Sanity Check (UsageSanityChecker.java). Specifically the "snapshot after removed" check, whose query is roughly:

SELECT count(*)
FROM   cloud_usage.cloud_usage cu
JOIN   cloud.snapshots s ON cu.usage_id = s.id
WHERE  cu.usage_type = 9
  AND  cu.start_date > s.removed;

i.e. usage records in cloud_usage.cloud_usage with a start_date AFTER the snapshot was already soft-deleted in cloud.snapshots. This drives the Usage Sanity Check failed mailer and feeds our Prometheus exporter.

On the running 4.22.1.0 (which includes 83ce006) we still see:

check	count
snapshot_after_removed	160
volume_after_removed	36
template_after_removed	0
vm_after_destroyed	0