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" <neil.jer...@metaswitch.com> 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 <neil.jer...@metaswitch.com >> <mailto:neil.jer...@metaswitch.com>> 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: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> -- >> Kevin Benton >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
