[openstack-dev] [Nova] bp proposal: discovery of peer instances through metadata service
Clint Byrum
clint at fewbar.com
Thu Feb 6 06:16:51 UTC 2014
Excerpts from Murray, Paul (HP Cloud Services)'s message of 2014-01-27 04:14:44 -0800:
> Hi Justin,
>
> My though process is to go back to basics. To perform discovery there is no getting away from the fact that you have to start with a well-known address that your peers can access on the network. The second part is a service/protocol accessible at that address that can perform the discovery. So the questions are: what well-known addresses can I reach? And is that a suitable place to implement the service/protocol.
>
> The metadata service is different to the others in that it can be accessed without credentials (correct me if I'm wrong), so it is the only possibility out of the openstack services if you do not want to have credentials on the peer instances. If that is not the case then the other services are options. All services require security groups and/or networks to be configured appropriately to access them.
>
> (Yes, the question "can all instances access the same metadata service" did really mean are they all local. Sorry for being unclear. But I think your answer is yes, they are, right?)
>
> Implementing the peer discovery in the instances themselves requires some kind of multicast or knowing a list of addresses to try. In both cases either the actual addresses or some name resolved through a naming service would do. Whatever is starting your instances does have access to at least nova, so it can find out if there are any running instances and what their addresses are. These could be used as the addresses they try first. These are the way that internet p2p services work and they work in the cloud.
>
That's kind of my point about using Heat. You can use any higher level
tool to achieve this by dropping the existing addresses into userdata
and then using a gossip protocol to "spread the word" to existing nodes
about new ones.
More information about the OpenStack-dev
mailing list