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" <neil.jer...@metaswitch.com <mailto: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> <mailto: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://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://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://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
