<p dir="ltr">How often does this happen? Is it on every call? If not, is it possible the forking logic in require_state is messing up the DB handle when it's invoked? </p>
<p dir="ltr">One way to make sure there aren't open transactions for testing is to just remove the "subtransactions=True" statement from update_port in the ML2 plugin. </p>
<div class="gmail_quote">On Jul 7, 2015 8:33 AM, "Neil Jerram" <<a href="mailto:Neil.Jerram@metaswitch.com">Neil.Jerram@metaswitch.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks, Kevin, but I believe we're already doing what you advise; please see <a href="https://github.com/Metaswitch/calico/blob/master/calico/openstack/mech_calico.py#L346-348" rel="noreferrer" target="_blank">https://github.com/Metaswitch/calico/blob/master/calico/openstack/mech_calico.py#L346-348</a><br>
<br>
Is there a way of checking that there aren't still any open transactions, when update_port_postcommit is called?<br>
<br>
Thanks,<br>
Neil<br>
<br>
<br>
On 07/07/15 15:57, Kevin Benton wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It sounds like something is starting a transaction before calling<br>
update_port on the core plugin. This will prevent the transaction from<br>
being completely closed even though ML2 is in the post_commit phase.<br>
<br>
In your db.get_port call, make sure you are using the same DB session<br>
from the context that was passed into update_port_postcommit and that<br>
will make sure you always have access to the current state even if the<br>
transaction isn't closed.<br>
<br>
On Tue, Jul 7, 2015 at 5:35 AM, Neil Jerram <<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a><br>
<mailto:<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a>>> wrote:<br>
<br>
I think there's something I'm not understanding about how Neutron's<br>
DB tables are related, and when one can safely read<br>
believed-to-be-committed information from them...<br>
<br>
My project's mechanism driver is handling a port update in which the<br>
fixed IPs are changing; specifically, a second fixed IP has been<br>
added to the port. It does this (for a reason I can explain if<br>
needed) by calling db.get_port(), in the update_port_postcommit hook.<br>
<br>
But we observe that the result of db.get_port() does not include the<br>
new fixed IP. Even though we're in the postcommit hook, and hence<br>
we assume that all the changes for that port have by now been committed.<br>
<br>
What are we misunderstanding here? My guess is that this is<br>
something to do with 'fixed_ips' not being a column directly in the<br>
Ports table, but instead calculated from relationships between the<br>
port ID and another (IPAllocation) table. We've seen a similar<br>
problem in the past with binding:host_id, for which the same is<br>
true, i.e. info is in the separate portbindings table.<br>
<br>
Or could it be that the transaction hasn't really been closed yet,<br>
when update_port_postcommit hook is called?<br>
<br>
(This is with Icehouse-level code, so it could be something that's<br>
been fixed...)<br>
<br>
Many thanks,<br>
Neil<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe:<br>
<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
--<br>
Kevin Benton<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>