Open Stack

Since this is post-commit, can you try using a new admin context for the
get_port call and see if it suffers from the same problem? So instead of
passing context._plugin_context, pass in ctx.get_admin_context().

On Fri, Jul 10, 2015 at 4:49 AM, Neil Jerram <Neil.Jerram at metaswitch.com>
wrote:

> 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.Jerram at metaswitch.com
>> <mailto: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>
>>         <mailto: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://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://OpenStack-dev-request@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://OpenStack-dev-request@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
>>
>>
> __________________________________________________________________________
> 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
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150713/d8e3f7fe/attachment.html>