bernardodemarco opened a new pull request, #11605:
URL: https://github.com/apache/cloudstack/pull/11605
### 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)
- [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
#### Bug Severity
- [ ] BLOCKER
- [ ] Critical
- [ ] Major
- [X] 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:
```bash
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
--
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]
