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 ? Phil From: Justin Santa Barbara [mailto:jus...@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! Justin
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
