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

Monty Taylor mordred at inaugust.com
Tue Jun 21 15:18:26 UTC 2016


On 06/21/2016 10:06 AM, Jay Faulkner wrote:
> 
> 
> 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?

I'm going to have to agree with Jay - and I believe with something Clint
said earlier.

Use metadata/config-drive to bootstrap you. Then use your actual tools
(puppet/chef/ansible/salt/juju/cfengine) to interact with the node once
it's enrolled in whatever you use to orchestrate cloud things. The best
part about doing that is that your orchestration layer can talk to the
OpenStack APIs AND to your nodes. Most of them also support key-value
pairs, as well as updating them.

> 
>> 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
> 
> 
> __________________________________________________________________________
> 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