<br><br><div class="gmail_quote">On Wed, Jul 18, 2012 at 5:17 AM, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<u></u>
<div bgcolor="#ffffff" text="#000000"><div>
On 07/18/2012 04:23 AM, Dan Wendlandt wrote:
<blockquote type="cite"><br></blockquote></div></div></blockquote><div><br></div><div>Hi Gary,</div><div><br></div><div>Removing much of the thread history, as I think we agree on the high-level goals. Now just focusing on the differences. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#ffffff" text="#000000"><div><blockquote type="cite"></blockquote></div><div>
<br>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<div>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. <br>
</div>
</div>
</blockquote>
<br></div>
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.</div></blockquote><div><br></div><div>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: </div>
<div>- port creation</div><div>- net creation</div><div>- subnet creation</div><div><br></div><div>and a specific topic for each entity after its created to learn about updates and deletes. </div><div><br></div><div>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.. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#ffffff" text="#000000"><div><blockquote type="cite">
<div class="gmail_quote">
<div>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). <br>
</div>
</div>
</blockquote>
<br></div>
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.</div></blockquote><div><br></div><div>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. </div>
<div><br></div><div>Dan</div><div><br></div><div><br></div><div> </div></div>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>