I'm developing Juju charms for Calico, an SDN compatible with OpenStack. We've found a problem where a change to the upstream nova-compute charm has broke our metadata for Juno / Kilo.
We use the nova-api-metadata package to serve metadata to VMs (and our charm (a subordinate of nova-compute) installs it), but we use Neutron and don't run any neutron metadata proxies. This is because we don't encapsulate any VM traffic, so we don't need the proxy to unencapsulate. The proxy is responsible for setting up the X-Instance-ID etc. headers in the metadata request, which are required by nova-api-metadata if it's configured with 'service_metadata_proxy' set to True.
The neutron_plugin_changed() hook in the nova-compute charm purges nova-api-metadata unless a shared secret is set, but setting this config option causes the nova-compute charm to set nova-api-metadata into service_metadata_proxy mode, which means it ignores all direct requests (i.e. ours).
Essentially, we can't get nova-compute to install nova-api-metadata for us, because setting the shared-secret on the relation which makes it do so also causes the charm to configure it in a way that won't work (service_metadata_proxy). We can't not set the shared-secret, because the nova-compute charm will then purge our packet! (See nova-compute charm's neutron_plugin_changed() relation).
Is it valid for the nova-compute charm to uninstall packages that another charm installed?
Hi Matt,
I've created a branch which lets the subordinate pass 'enable-metadata: True' to the nova-compute charm which will stop it from purging the package. Could you take a look at the attached merge proposal ( https:/
Thanks
Liam