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

Jay Faulkner jay at jvf.cc
Tue Jun 21 15:06:22 UTC 2016



On 6/17/16 3:04 PM, Joshua Harlow wrote:
> 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 http://169.254.169.254/openstack/latest/meta_data.json | 
> 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)?
>
I would be -1 to instituting this change as well, as it would be 
impossible for some hypervisors/drivers (such as Ironic) to implement. 
Additionally, how could you ensure the tenant OS didn't have the 
configdrive mounted or otherwise in use?

Thanks,
Jay

> 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).
>
> -Josh
>
> __________________________________________________________________________ 
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list