nagaboinaramgopal opened a new pull request, #14157:
URL: https://github.com/apache/cloudstack/pull/14157
### Description
On the virtual router, the `latest/cloud-domain` and
`latest/cloud-domain-id` rewrite rules in
`systemvm/debian/var/www/html/latest/.htaccess` point at the `vm-id` metadata
file, so a guest asking its router for either gets its VM id instead of the
domain name or domain id. The router already writes the right `cloud-domain`
and `cloud-domain-id` files when `metadata.allow.expose.domain` is enabled, and
`latest/meta-data/cloud-domain` returns them correctly through the generic
`meta-data/` rule. This points each rule at its own file.
When the domain is not exposed, the old rules also handed out the VM id for
these two paths. With this change they return 404, the same as
`latest/meta-data/cloud-domain`.
`configure.py` (`__htaccess`) also appends `^cloud-domain$` and
`^cloud-domain-id$` rules pointing at the right files when it writes the
guest's metadata, but it only appends and never touches the static lines, and
the static `^cloud-domain/?$` rules come first in the file, so they win.
The same lines are on 4.20, 4.22 and main, so this targets 4.20.
### 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
#### Feature/Enhancement Scale
- [ ] Major
- [ ] Minor
#### Bug Severity
- [ ] BLOCKER
- [ ] Critical
- [ ] Major
- [x] Minor
- [ ] Trivial
### Screenshots (if appropriate):
N/A
### How Has This Been Tested?
Live tested on a KVM zone with an isolated network and a virtual router,
requesting the metadata from inside a guest with `wget -qO-
http://<router>/latest/<path>`. The router picks up `.htaccess` changes on the
next request, so the fixed file was applied on the running router. Values are
shown by what they matched.
With `metadata.allow.expose.domain=true`, before the change:
latest/vm-id VM id
latest/cloud-domain VM id
latest/cloud-domain-id VM id
latest/meta-data/cloud-domain domain name
latest/meta-data/cloud-domain-id domain id
With the change:
latest/vm-id VM id
latest/cloud-domain domain name
latest/cloud-domain-id domain id
latest/meta-data/cloud-domain domain name
latest/meta-data/cloud-domain-id domain id
With `metadata.allow.expose.domain=false` and a new guest, before the change:
latest/vm-id VM id
latest/cloud-domain VM id
latest/cloud-domain-id VM id
latest/meta-data/cloud-domain 404 Not Found
latest/meta-data/cloud-domain-id 404 Not Found
With the change:
latest/vm-id VM id
latest/cloud-domain 404 Not Found
latest/cloud-domain-id 404 Not Found
latest/meta-data/cloud-domain 404 Not Found
latest/meta-data/cloud-domain-id 404 Not Found
The file is part of `cloud-scripts.tgz` (the systemvm build copies
`systemvm/debian/`), so routers get it when they are patched on restart.
#### How did you try to break this feature and the system with this change?
Only the two rules change. `latest/vm-id`, the other metadata paths and the
generic `meta-data/` rule return the same values as before, and user data is
not touched.
--
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]
