<br><br><div class="gmail_quote">On 23 July 2012 09:02, Dan Wendlandt <span dir="ltr"><<a href="mailto:dan@nicira.com" target="_blank">dan@nicira.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div class="im">On Sun, Jul 22, 2012 at 5:51 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><br><blockquote type="cite"><div class="gmail_quote">
</div>
</blockquote>
<br></div>
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 href="https://review.openstack.org/#/c/9591" target="_blank">https://review.openstack.org/#/c/9591</a><br>
<br>
This can certainly be improved and optimized. What are your
thoughts?<br></div></blockquote><div><br></div></div><div>Based on your follow-up emails, I think we're now thinking similarly about this. Just to be clear though, for updates I was talking about a different topic for each entity that has its own UUID (e.g., topic port-update-f01c8dcb-d9c1-4bd6-9101-1924790b4b45) </div>
</div></blockquote><div><br></div><div><br></div><div>From my limited experience with RPC, I have never seen per-object topics as we are proposing here. Nevertheless, I think they're a good idea and I am not aware of any reasons for which this should impact the scalability of the underlying message queue.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im">
<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">
<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></div></blockquote><div><br></div></div><div>Agreed. There are a couple options here: direct DB access (no polling, just direct fetching), admin API extensions, or custom RPC calls. Each has pluses and minuses. Perhaps my real goal here would be better described as "if there's an existing plugin agnostic way to doing X, our strong bias should be to use it until presented with concrete evidence to the contrary". For example, should a DHCP client create a port for the DHCP server via the standard API, or via a custom API or direct DB access? My strong bias would be toward using the standard API. </div>
</div></blockquote><div><br></div><div>I totally agree with this approach. Should we be presented with an "evidence of the contrary", I would then use API extensions first and then, only if necessary, custom RPC calls. If we end up in a situation where we feel we need direct DB access, I would say we are in a very bad place and need to back to the drawing board!</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im">
<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">
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></div></blockquote><div><br></div></div><div>That sounds valuable. </div><div class="im"><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">
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></div></blockquote><div><br></div></div><div>Agreed. I think we need to decide on this at monday's IRC meeting, so we can move forward. Given F-3 deadlines, I'm well aware that I'll have to be pragmatic here :) </div>
</div></blockquote><div><br></div><div>I believe Yong stated in a different thread (or in the code review discussion) that his notification mechanism was trying to address a somewhat different use case. Given the looming deadline, I would probably discuss in today's (or tomorrow's for the non-Euro netstacker's) meeting whether there is any major reason for which both patches cannot live together and then proceed to merge both. When planning Grizzly we can then look back at them and see if and how these mechanisms could be merged.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im">
<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">
<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)</div></blockquote><div><br></div></div><div>Sorry, wish I could help, but I'm probably in the same boat as you on this one. </div></div></blockquote><div><br>
</div><div>I am afraid I cannot be of great help too. But there's a high chance nova+libvirt developers already faced and solved this issue.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div> </div><div>I'm going to make sure we have a good chunk of time to discuss this during the IRC meeting on monday (sorry, I know that's late night for you...). </div><span class="HOEnZb"><font color="#888888">
<div><br></div><div>Dan</div></font></span><div class="im"><div><br></div><div><br></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">
<br>
Thanks<span><font color="#888888"><br>
Gary</font></span><div><br>
<blockquote 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 href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
<div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
</div>
</div>
<br>
</blockquote>
<br>
</div></div>
</blockquote></div></div><br><br clear="all"><div><br></div>-- <br><div class="HOEnZb"><div class="h5">~~~~~~~~~~~~~~~~~~~~~~~~~~~<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>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br>