systemvm-registration: update seeded template_store_ref sizes

[rp-]

Description

Pre-seeded template storages always had there pre initialized 0 sizes and would never be updated.
This makes later problems, when the primary storage should pre-allocate the volume as it doesn't know the size
and would fail or maybe try to delay the allocation until the agent code knows the size.
This updates the sizes from the template.properties files on the validateIfSeeded check.

The issue was found while reviewing #10132

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• 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
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

Started a fresh KVM cluster with preseeded systemvm template from cloud-install-sys-tmplt on Linstor primary storage.

How did you try to break this feature and the system with this change?

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 26 lines in your changes missing coverage. Please review.

Project coverage is 15.16%. Comparing base (c1bc57b) to head (ca6c865).
Report is 9 commits behind head on 4.19.

Files with missing lines	Patch %	Lines
...om/cloud/upgrade/SystemVmTemplateRegistration.java	0.00%	24 Missing ⚠️
...ain/java/com/cloud/storage/StorageManagerImpl.java	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##               4.19   #10317   +/-   ##
=========================================
  Coverage     15.16%   15.16%           
- Complexity    11302    11303    +1     
=========================================
  Files          5408     5408           
  Lines        473931   473950   +19     
  Branches      57844    57845    +1     
=========================================
+ Hits          71866    71869    +3     
- Misses       394034   394048   +14     
- Partials       8031     8033    +2     

Flag	Coverage Δ
uitests	4.29% <ø> (ø)
unittests	15.88% <0.00%> (ø)

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.

[weizhouapache]

@rp-
this seems to be an issue with the script cloud-install-sys-tmplt , right ?

[rp-]

@rp- this seems to be an issue with the script cloud-install-sys-tmplt , right ?

not directly, as the script only updates the vm_template table and before cloudstack-management hasn't upgraded all the sql, there isn't even a table template_store_ref yet. So you can only fix that issue within the code.

There is this code here:

cloudstack/engine/storage/image/src/main/java/org/apache/cloudstack/storage/image/TemplateServiceImpl.java

Line 1242 in cd81398

tmpltStore.setPhysicalSize(0); // no size information for

Which does add the seeded entries, but at that time, no secondary storage is mounted, so you can't get the correct sizes.

[DaanHoogland]

@blueorangutan package

[blueorangutan]

@DaanHoogland a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

[weizhouapache]

@rp- this seems to be an issue with the script cloud-install-sys-tmplt , right ?

not directly, as the script only updates the vm_template table and before cloudstack-management hasn't upgraded all the sql, there isn't even a table template_store_ref yet. So you can only fix that issue within the code.

There is this code here:

cloudstack/engine/storage/image/src/main/java/org/apache/cloudstack/storage/image/TemplateServiceImpl.java

Line 1242 in cd81398

tmpltStore.setPhysicalSize(0); // no size information for

Which does add the seeded entries, but at that time, no secondary storage is mounted, so you can't get the correct sizes.

thanks @rp-

[blueorangutan]

Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 12323

[weizhouapache]

@blueorangutan test

[blueorangutan]

@weizhouapache a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests

[DaanHoogland]

clgtm

[blueorangutan]

[SF] Trillian test result (tid-12295)
Environment: kvm-ol8 (x2), Advanced Networking with Mgmt server ol8
Total time taken: 47219 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr10317-t12295-kvm-ol8.zip
Smoke tests completed. 132 look OK, 1 have errors, 0 did not run
Only failed and skipped tests results shown below:

Test	Result	Time (s)	Test File
test_12_start_vm_multiple_volumes_allocated	Error	15.21	test_vm_life_cycle.py

[rp-]

[SF] Trillian test result (tid-12295) Environment: kvm-ol8 (x2), Advanced Networking with Mgmt server ol8 Total time taken: 47219 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr10317-t12295-kvm-ol8.zip Smoke tests completed. 132 look OK, 1 have errors, 0 did not run Only failed and skipped tests results shown below:

Test Result Time (s) Test File
test_12_start_vm_multiple_volumes_allocated Error 15.21 test_vm_life_cycle.py

Hmm as far as I see the fail comes from a VM i-250-346-VM that couldn't be found in the database?
Not sure if this can be related to this change?

[weizhouapache]

[SF] Trillian test result (tid-12295) Environment: kvm-ol8 (x2), Advanced Networking with Mgmt server ol8 Total time taken: 47219 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr10317-t12295-kvm-ol8.zip Smoke tests completed. 132 look OK, 1 have errors, 0 did not run Only failed and skipped tests results shown below:
Test Result Time (s) Test File
test_12_start_vm_multiple_volumes_allocated Error 15.21 test_vm_life_cycle.py

Hmm as far as I see the fail comes from a VM i-250-346-VM that couldn't be found in the database? Not sure if this can be related to this change?

@rp-
ignore the failure. it is addressed in #10323