On Wed, Jul 18, 2012 at 5:17 AM, Gary Kotton <gkot...@redhat.com> wrote:
> ** > On 07/18/2012 04:23 AM, Dan Wendlandt wrote: > > > Hi Gary, Removing much of the thread history, as I think we agree on the high-level goals. Now just focusing on the differences. > > > For example, a DHCP agent handling all DHCP for a deployment might > register for create/update/delete operations on subnets + ports, whereas a > plugin agent might only register for updates from the ports that it sees > locally on the hypervisor. Conceptually, you could think of there being a > 'topic' per port in this case, though we may need to implement it > differently in practice. > > > The agent ID is currently stored in the database (this is for the > configuration sync mechanism). I think that adding an extra column > indicating the capabilities enables the service to notify the agents. The > issue is how refined can the updates be - we want to ensure that we have a > scalable architecture. > I think either we can implement the filtering ourselves using a mechanism like this, or we can rely on the message bus to do it for us. I'm not really familiar with the scalability of various message bus implementations, but a simple model would be that there's a topic for: - port creation - net creation - subnet creation and a specific topic for each entity after its created to learn about updates and deletes. as I said, we may need to implement this logic ourselves is using many such topics would not be scalable, but this seems like the kind of think a message bus should be good at.. > In general, I think it is ideal if these external agents can use > standard mechanisms and formats as much as possible. For example, after > learning that port X was created, the DHCP agent can actually use a > standard webservice GET to learn about the configuration of the port (or if > people feel that such information should be included in the notification > itself, this notification data uses the same format as the webservice > API). > > > I am not sure that I agree here. If the service is notifying the agent > then why not have the information being passed in the message (IP + mac > etc.) There is no need for the GET operation. > My general bias here is that if there are now two ways to fetch every type of information (one via the standard "public" interface and another via the "internal" interface with a different implementation) that is twice the testing, updating, documenting that we have to do. Perhaps the two problems we're trying to solve are sufficiently different that they require two different mechanisms, but in my use cases I haven't seen that yet. Dan ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
