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
