Fix the stored system VMs paths when introducing the first secondary storage of a new zone

[bernardodemarco]

Description

When a new zone is added to an environment, ACS replicates the metadata of system VMs templates (stored in the cloud.template_store_ref table) to the secondary storage of the new zone. However, the install path of the templates are stored as template/tmpl/1/<template-id>, in which 1 represents the ID of the system's account. Thus, ACS does not consider the possibility that a cloud operator could have manually registered the template.

So, if an operator with account with ID 2, for example, registers a system VM template with ID 200, the template's install path will be stored as /template/tmpl/1/200 and not as /template/tmpl/2/200. Additionally, if one system VM template is manually copied from one secondary storage to another, when deploying the system VMs of the new zones, the operation will fail, because the inexistent path (/template/tmpl/1/200) will be accessed in the storage.

Therefore, changes have been made to consider the accounts that registered system VM templates when replicating the templates install paths in the DB. With that, in the previous example, the template's install path will be stored as template/tmpl/2/200 and the deployment of system VMs will not fail.

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

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

Before applying the PR's changes, I performed the following actions:

• Registered a system VM template with an Admin account and marked it as SYSTEM
• Verified that the template's path in the secondary storage was equal to /mnt/sec-nfs-01/template/tmpl/2/204
• Created a secondary storage for the new zone. When configuring it, the contents of /mnt/sec-nfs-01/template/tmpl/2/204/* were replicated to /mnt/sec-nfs-02/template/tmpl/2/204/*
• Added the zone through the ACS zone creation wizard
• When enabling the zone, the system VM deployment failed, because the template's install path was incorrectly persisted in the DB:

WARN  [c.c.v.VirtualMachineManagerImpl] (Work-Job-Executor-15:ctx-4b83a953 job-66/job-101 ctx-e16507fd) (logid:19ac32a3) Unable to contact resource.
com.cloud.exception.StorageUnavailableException: Resource [StoragePool:2] is unreachable: Unable to create volume [{"name":"ROOT-15","uuid":"d243b010-2068-487b-a4a3-a85e153f1c17"}] due to [com.cloud.utils.exception.CloudRuntimeException: org.libvirt.LibvirtException: internal error: Child process (/usr/bin/mount -o nodev,nosuid,noexec 192.168.100.230:/mnt/sec-nfs-02/template/tmpl/1/204 /mnt/eb24a377-ec10-3cfe-aa7c-91ecd46d8b9f) unexpected exit status 32: Created symlink /run/systemd/system/remote-fs.target.wants/rpc-statd.service → /usr/lib/systemd/system/rpc-statd.service.
mount.nfs: mounting 192.168.100.230:/mnt/sec-nfs-02/template/tmpl/1/204 failed, reason given by server: No such file or directory

---

After applying the PR's changes, I verified that:

• After introducing the new zone, the template's install path was correctly persisted in the DB
• After enabling the zone, its system VMs were correctly provisioned

[bernardodemarco]

@blueorangutan package

[blueorangutan]

@bernardodemarco 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.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 16.17%. Comparing base (9349b69) to head (320d989).
⚠️ Report is 20 commits behind head on 4.20.

Files with missing lines	Patch %	Lines
.../cloudstack/storage/image/TemplateServiceImpl.java	0.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##               4.20   #11605   +/-   ##
=========================================
  Coverage     16.17%   16.17%           
- Complexity    13294    13296    +2     
=========================================
  Files          5656     5656           
  Lines        498082   498101   +19     
  Branches      60415    60424    +9     
=========================================
+ Hits          80569    80583   +14     
+ Misses       408551   408549    -2     
- Partials       8962     8969    +7     

Flag	Coverage Δ
uitests	4.00% <ø> (-0.01%)	⬇️
unittests	17.03% <0.00%> (+<0.01%)	⬆️

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.

[blueorangutan]

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

[weizhouapache]

@blueorangutan package

[blueorangutan]

@weizhouapache 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.

[blueorangutan]

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

[weizhouapache]

code lgtm

not tested yet

[DaanHoogland]

clgtm

[rosi-shapeblue]

@blueorangutan package

[blueorangutan]

@rosi-shapeblue 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.

[blueorangutan]

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