Open Stack

Excerpts from Robert Collins's message of 2013-11-19 16:22:41 -0800:
> On 20 November 2013 13:00, Sean Dague <sean at dague.net> wrote:
> >> As long as the metadataservice doesn't move out :) - that one I think
> >> is pretty core and we have no native replacement [configdrive is not a
> >> replacement :P].
> >
> >
> > Slightly off tangent thread.
> >
> > So we recently moved devstack gate to do con fig drive instead of metadata
> > service, and life was good (no one really noticed). In what ways is
> > configdrive insufficient compared to metadata service? And is that something
> > that we should be tackling?
> 
> * The metadata service can be trivially updated live - and Heat wants
> to use this to get rid of it's own metadata service... whereas config
> drive requires unplugging the device, updating the data and replugging
> - and thats a bit more invasive.
> 

This one is key. Both Trove and Savanna have run into the same
limitation as Heat: networks that cannot reach the API endpoints don't
get to have their API specific Metadata that updates over time. By
putting it in the EC2 metadata service, we can access it via the Neutron
proxy and then Heat/Trove/Savanna can update it later to provide a
control bus for in-instance tools.