<!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/22/2012 03:51 PM, Gary Kotton wrote:
<blockquote cite="mid:500BF73A.309@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
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>
</blockquote>
<br>
I have given this additional thought. One of the problems with the
approach that I have suggested is that the plugin/service will have
to send n updates instead of 1. I am going to try what you suggested
- it is a minor tweak to the code.<br>
<br>
<blockquote cite="mid:500BF73A.309@redhat.com" type="cite"> <br>
I have implemented something similar in <a moz-do-not-send="true"
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 moz-do-not-send="true"
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>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>