[openstack-dev] [Nova] bp proposal: discovery of peer instances through metadata service

Day, Phil philip.day at hp.com
Fri Jan 24 13:43:04 UTC 2014

Hi Justin,

I can see the value of this, but I'm a bit wary of the metadata service extending into a general API - for example I can see this extending into a debate about what information needs to be made available about the instances (would you always want all instances exposed, all details, etc) - if not we'd end up starting to implement policy restrictions in the metadata service and starting to replicate parts of the API itself.

Just seeing instances launched before me doesn't really help if they've been deleted (but are still in the cached values) does it ?

Since there is some external agent creating these instances, why can't that just provide the details directly as user defined metadata ?


From: Justin Santa Barbara [mailto:justin at fathomdb.com]
Sent: 23 January 2014 16:29
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Nova] bp proposal: discovery of peer instances through metadata service

Would appreciate feedback / opinions on this blueprint: https://blueprints.launchpad.net/nova/+spec/first-discover-your-peers

The idea is: clustered services typically run some sort of gossip protocol, but need to find (just) one peer to connect to.  In the physical environment, this was done using multicast.  On the cloud, that isn't a great solution.  Instead, I propose exposing a list of instances in the same project, through the metadata service.

In particular, I'd like to know if anyone has other use cases for instance discovery.  For peer-discovery, we can cache the instance list for the lifetime of the instance, because it suffices merely to see instances that were launched "before me".  (peer1 might not join to peer2, but peer2 will join to peer1).  Other use cases are likely much less forgiving!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140124/93ecb435/attachment.html>

More information about the OpenStack-dev mailing list