Open Stack

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.Jerram at 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.Jerram at metaswitch.com
>> <mailto:Neil.Jerram at 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-request at lists.openstack.org?subject:unsubscribe
>>     <http://OpenStack-dev-request@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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150707/1855597a/attachment.html>