systemvm: serve cloud-domain and cloud-domain-id from their own metadata files

[nagaboinaramgopal]

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)
• 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):

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.