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> 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://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
