Open Stack

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
>