<html><body>
<p><font size="2" face="sans-serif">Zang, thanks for your comments.</font><br>
<br>
<font size="2" face="sans-serif">I think what you are suggesting is perhaps orthogonal to having Resource and Agent drivers. By that I mean we can have what you are suggesting and keep the Resource and Agent drivers. The reason for having Resource drivers is to provide the means for possibly extending what an agent does in response to say changes to a port in a modular way. We can restrict the access to Resource drivers from the events loop only. That restriction is not there in the current model but would adding that address your concerns? What are your thoughts? As Salvatore has mentioned in his email in this thread, that is what the current OVS agent does wrt port updates. That is, the update to ports get processed from the events loop.</font><br>
<br>
<font size="2" face="sans-serif">As a separate but relevant issue, we can and should discuss whether having the Resource and Agent drivers is useful in making the agent more modular. The idea behind using these drivers is to have the agent use a collection of drivers rather than mixin classes so we can more easily select what (and how) functionalities an agent support and reuse as much as we can across L2 agents. Are there better ways of achieving this? Any thoughts?</font><br>
<br>
<font size="2" face="sans-serif">Best,</font><br>
<br>
<font size="2" face="sans-serif">Mohammad</font><br>
<br>
<br>
<br>
<img width="16" height="16" src="cid:1__=0ABBF66EDFFDD6528f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Zang MingJie ---06/19/2014 06:27:31 AM---Hi: I don't like the idea of ResourceDriver and AgentDriver."><font size="2" color="#424282" face="sans-serif">Zang MingJie ---06/19/2014 06:27:31 AM---Hi: I don't like the idea of ResourceDriver and AgentDriver. I suggested</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">Zang MingJie <zealot0630@gmail.com></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">"OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>, </font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">06/19/2014 06:27 AM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: [openstack-dev] [Neutron][ML2] Modular L2 agent architecture</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt><font size="2">Hi:<br>
<br>
I don't like the idea of ResourceDriver and AgentDriver. I suggested<br>
use a singleton worker thread to manager all underlying setup, so the<br>
driver should do nothing other than fire a update event to the worker.<br>
<br>
The worker thread may looks like this one:<br>
<br>
# the only variable store all local state which survives between<br>
different events, including lvm, fdb or whatever<br>
state = {}<br>
<br>
# loop forever<br>
while True:<br>
event = ev_queue.pop()<br>
if not event:<br>
sleep() # may be interrupted when new event comes<br>
continue<br>
<br>
origin_state = state<br>
new_state = event.merge_state(state)<br>
<br>
if event.is_ovsdb_changed():<br>
if event.is_tunnel_changed():<br>
setup_tunnel(new_state, old_state, event)<br>
if event.is_port_tags_changed():<br>
setup_port_tags(new_state, old_state, event)<br>
<br>
if event.is_flow_changed():<br>
if event.is_flow_table_1_changed():<br>
setup_flow_table_1(new_state, old_state, event)<br>
if event.is_flow_table_2_changed():<br>
setup_flow_table_2(new_state, old_state, event)<br>
if event.is_flow_table_3_changed():<br>
setup_flow_table_3(new_state, old_state, event)<br>
if event.is_flow_table_4_changed():<br>
setup_flow_table_4(new_state, old_state, event)<br>
<br>
if event.is_iptable_changed():<br>
if event.is_iptable_nat_changed():<br>
setup_iptable_nat(new_state, old_state, event)<br>
if event.is_iptable_filter_changed():<br>
setup_iptable_filter(new_state, old_state, event)<br>
<br>
state = new_state<br>
<br>
when any part has been changed by a event, the corresponding setup_xxx<br>
function rebuild the whole part, then use the restore like<br>
`iptables-restore` or `ovs-ofctl replace-flows` to reset the whole<br>
part.<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><tt><font size="2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font size="2"><br>
<br>
</font></tt><br>
</body></html>