<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 07/19/2012 07:11 PM, Dan Wendlandt wrote:
<blockquote
cite="mid:CA+0XJm9KSYkoxdbaEZwXEL_1NHy72QpG9GUY=VjG_qs003m2jg@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">On Wed, Jul 18, 2012 at 5:17 AM, Gary
Kotton <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<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: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<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>
</blockquote>
<br>
This is an interesting idea. In addition to the creation we will
also need the update. I would prefer that the agents would have one
topic - that is for all updates. When an agent connects to the
plugin it will register the type of operations that are supported on
the specific agent. The agent operations can be specific as bit
masks.<br>
<br>
I have implemented something similar in
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/9591">https://review.openstack.org/#/c/9591</a><br>
<br>
This can certainly be improved and optimized. What are your
thoughts?<br>
<br>
In addition to this we have a number of issues where the plugin does
not expose the information via the standard API's - for example the
VLAN tag (this is being addressed via extensions in the provider
networks feature)<br>
<br>
There are a number of things that we need to address:<br>
1. Support for different plugins - if acceptable then the model
above needs to be more generic and a common interface should be
defined. <br>
2. Support for different agents. This is pretty simple - for example
the DHCP agent. It has to do the following:<br>
i. use the health check mechanism (this registers the mask for
the notification updates)<br>
ii. add in support for port creation (I guess that I can add
this as part of this patch)<br>
3. Logging. At the moment the agents do not have a decent logging
mechanism. This makes debugging the RPC code terribly difficult.
This was scheduled for F-3. I'll be happy to add this if there are
no objections.<br>
4. We need to discuss the notifications that Yong added and how
these two methods can interact together. More specifically I think
that we need to address the configuration files.<br>
<br>
The RPC code requires that the eventlet monkey patch be set. This
cause havoc when I was using the events from pyudev for new device
creation. At the moment I have moved the event driven support to
polling (if anyone who reads this is familiar with the issue or has
an idea on how to address it any help will be great)<br>
<br>
<blockquote
cite="mid:CA+0XJm9KSYkoxdbaEZwXEL_1NHy72QpG9GUY=VjG_qs003m2jg@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>and a specific topic for each entity after its created to
learn about updates and deletes. <br>
</div>
</div>
</blockquote>
<br>
I prefer having a cast to a specific topic than a broadcast all.
(please look at
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/9591/3/quantum/plugins/linuxbridge/lb_quantum_plugin.py">https://review.openstack.org/#/c/9591/3/quantum/plugins/linuxbridge/lb_quantum_plugin.py</a>
- method <span class="pln">update_port - line 174).</span><br>
<br>
<blockquote
cite="mid:CA+0XJm9KSYkoxdbaEZwXEL_1NHy72QpG9GUY=VjG_qs003m2jg@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<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: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
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. <br>
</div>
</div>
</blockquote>
<br>
This is a tough one. On one hand I agree with you. On the other I
think that we should have a better tuned and optimized system. Yes,
this may require a bit more effort but I think that it is more
robust. Another issue is that each plugin has its own traits and
characteristics. Private additional data may have to be transferred.<br>
<br>
Thanks<br>
Gary<br>
<blockquote
cite="mid:CA+0XJm9KSYkoxdbaEZwXEL_1NHy72QpG9GUY=VjG_qs003m2jg@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>Dan</div>
<div><br>
</div>
<div><br>
</div>
<div> </div>
</div>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
Dan Wendlandt
<div>Nicira, Inc: <a moz-do-not-send="true"
href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
<div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
</div>
</div>
<br>
</blockquote>
<br>
</body>
</html>