<div dir="ltr">Thanks Kyle,<div><br></div><div>More comments inline.</div><div><br></div><div>Salvatore</div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On 25 November 2013 16:03, Kyle Mestery (kmestery) <span dir="ltr"><<a href="mailto:kmestery@cisco.com" target="_blank">kmestery@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Nov 25, 2013, at 8:28 AM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:<br>

><br>
> Hi,<br>
><br>
> I've been recently debugging some issues I've had with the OVS agent, and I found out that in many  cases (possibly every case) the code just logs errors from ovs-vsctl and ovs-ofctl without taking any action in the control flow.<br>

><br>
> For instance, the routine which should do the wiring for a port, port_bound [1], does not react in any way if it fails to configure the local vlan, which I guess means the port would not be able to send/receive any data.<br>

><br>
> I'm pretty sure there's a good reason for this which I'm missing at the moment. I am asking because I see a pretty large number of ALARM_CLOCK errors returned by OVS commands in gate logs (see bug [2]), and I'm not sure whether it's ok to handle them as the OVS agent is doing nowadays.<br>

><br>
</div>Thanks for bringing this up Salvatore. It looks like the underlying run_vstcl [1] provides an ability to raise exceptions on errors, but this is not used by most of the callers of run_vsctl. Do you think we should be returning the exceptions back up the stack to callers to handle? I think that may be a good first step.<br>
</blockquote><div><br></div><div>I think it makes sense to start to handle errors; as they often happen in the agent's rpc loop simply raising will probably just cause the agent to crash.</div><div>I looked again at the code and it really seems it's silently ignoring errors from ovs command.</div>
<div>This actually makes sense in some cases. For instance the l3 agent might remove a qr-xxx or qg-xxx port while the l2 agent is in the middle of its iteration.</div><div><br></div><div>There are however cases in which the exception must be handled.</div>
<div>In cases like the ALARM_CLOCK error, either a retry mechanism or marking the port for re-syncing at the next iteration might make sense.</div><div>Other error cases might be unrecoverable; for instance when a port disappears. In that case it seems reasonable to put the relevant neutron port in ERROR state, so that the user is aware that the port anymore.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Kyle<br>
<br>
[1] <a href="https://github.com/openstack/neutron/blob/master/neutron/agent/linux/ovs_lib.py#L52" target="_blank">https://github.com/openstack/neutron/blob/master/neutron/agent/linux/ovs_lib.py#L52</a><br>
<div class="im"><br>
> Regards,<br>
> Salvatore<br>
><br>
> [1] <a href="https://github.com/openstack/neutron/blob/master/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py#L599" target="_blank">https://github.com/openstack/neutron/blob/master/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py#L599</a><br>

> [2] <a href="https://bugs.launchpad.net/neutron/+bug/1254520" target="_blank">https://bugs.launchpad.net/neutron/+bug/1254520</a><br>
</div>> _______________________________________________<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>
<br>
<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>
</blockquote></div><br></div></div></div>