Since this is post-commit, can you try using a new admin context for the get_port call and see if it suffers from the same problem? So instead of passing context._plugin_context, pass in ctx.get_admin_context().
On Fri, Jul 10, 2015 at 4:49 AM, Neil Jerram <[email protected]> wrote: > Sorry to leave this unanswered. > > It happens every time (as far as we've tested so far). > > A pragmatic fix appears to be to explicitly requery the IPAllocation > table, as you can see in the two commits here: > > https://github.com/Metaswitch/calico/commit/5512ce7dd50db414f161bddcef17b0846a1466ac > > https://github.com/Metaswitch/calico/commit/4ecaf3568af52ef9cc29662a3b94672540056f05 > > But still it seems a shame if this is needed. > > Neil > > > On 07/07/15 22:32, Kevin Benton wrote: > >> 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? >> >> 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. >> >> On Jul 7, 2015 8:33 AM, "Neil Jerram" <[email protected] >> <mailto:[email protected]>> wrote: >> >> Thanks, Kevin, but I believe we're already doing what you advise; >> please see >> >> https://github.com/Metaswitch/calico/blob/master/calico/openstack/mech_calico.py#L346-348 >> >> Is there a way of checking that there aren't still any open >> transactions, when update_port_postcommit is called? >> >> Thanks, >> Neil >> >> >> On 07/07/15 15:57, Kevin Benton wrote: >> >> It sounds like something is starting a transaction before calling >> update_port on the core plugin. This will prevent the >> transaction from >> being completely closed even though ML2 is in the post_commit >> phase. >> >> In your db.get_port call, make sure you are using the same DB >> session >> from the context that was passed into update_port_postcommit and >> that >> will make sure you always have access to the current state even >> if the >> transaction isn't closed. >> >> On Tue, Jul 7, 2015 at 5:35 AM, Neil Jerram >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] >> >> <mailto:[email protected]>>> wrote: >> >> I think there's something I'm not understanding about how >> Neutron's >> DB tables are related, and when one can safely read >> believed-to-be-committed information from them... >> >> My project's mechanism driver is handling a port update in >> which the >> fixed IPs are changing; specifically, a second fixed IP has >> been >> added to the port. It does this (for a reason I can explain >> if >> needed) by calling db.get_port(), in the >> update_port_postcommit hook. >> >> But we observe that the result of db.get_port() does not >> include the >> new fixed IP. Even though we're in the postcommit hook, >> and hence >> we assume that all the changes for that port have by now >> been committed. >> >> What are we misunderstanding here? My guess is that this is >> something to do with 'fixed_ips' not being a column >> directly in the >> Ports table, but instead calculated from relationships >> between the >> port ID and another (IPAllocation) table. We've seen a >> similar >> problem in the past with binding:host_id, for which the same >> is >> true, i.e. info is in the separate portbindings table. >> >> Or could it be that the transaction hasn't really been >> closed yet, >> when update_port_postcommit hook is called? >> >> (This is with Icehouse-level code, so it could be something >> that's >> been fixed...) >> >> Many thanks, >> Neil >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> < >> http://[email protected]?subject:unsubscribe> >> >> < >> http://[email protected]?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> -- >> Kevin Benton >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> < >> http://[email protected]?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> <http://[email protected]?subject:unsubscribe >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kevin Benton
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
