[openstack-dev] [nova] ability to set metadata on instances (but config drive is not updated)

Clint Byrum clint at fewbar.com
Sun Jun 19 17:57:53 UTC 2016

Excerpts from Joshua Harlow's message of 2016-06-17 15:04:38 -0700:
> Hi folks,
> I was noticing that its possible to do something like:
> $ nova meta josh-testr3 set "e=f"
> Then inside the VM I can do the following to eventually see that this 
> changes shows up in the instance metadata exposed at the following:
> $ curl -s | 
> python -mjson.tool
> {
>      ...
>      "hostname": "josh-testr3.cloud.phx3.gdg",
>      "launch_index": 0,
>      "meta": {
>          ...
>          "e": "f",
>          ..
>       }
>       ...
> }
> Now if I am using the configdrive instead of the metadata server at that 
> special/magic ip that same metadata never seems to change (I assume the 
> configdrive would have to be 'ejected' and then a new configdrive 
> created and then that configdrive 'reinserted'); was anyone aware of a 
> bug that would solve this (it does appear to be a feature difference 
> that could/should? be solved)?

That's not a bug. AFAIK, it was never intended to be updated.

> Why this is something useful (from my view) is that we (at godaddy) have 
> a cron job that polls that metadata periodically and it generates a 
> bunch of polling traffic (especially when each VM does this) and that 
> traffic could be removed if such a 'eject' and 'reinsert' happens 
> instead (since then the cron job could become a small program that 
> listens for devices being inserted/removed and does the needed actions 
> then, which is better than polling endlessly for data that hasn't changed).

I think you're abusing Nova to do what your config management system
should be doing. The config drive and metadata service are not meant
to be continuously polled or updated, they're for bootstrapping into
a continuous config management system.

I'd suggest putting your metadata into something that is appropriately
scaled and doesn't have to do backflips to figure out your instance
ID by looking up your network address in another service, or using a
push technology like Ansible or mcollective (does anybody still use
that?) which doesn't suffer from needless polling.

Could we make Nova do this? Yes. Do we need to? No, It's solved by
everyone else just fine without hypervisor collaboration, and Nova has
more important things to do.

More information about the OpenStack-dev mailing list