<div dir="ltr">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().</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 10, 2015 at 4:49 AM, Neil Jerram <span dir="ltr"><<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sorry to leave this unanswered.<br>
<br>
It happens every time (as far as we've tested so far).<br>
<br>
A pragmatic fix appears to be to explicitly requery the IPAllocation table, as you can see in the two commits here:<br>
<a href="https://github.com/Metaswitch/calico/commit/5512ce7dd50db414f161bddcef17b0846a1466ac" rel="noreferrer" target="_blank">https://github.com/Metaswitch/calico/commit/5512ce7dd50db414f161bddcef17b0846a1466ac</a><br>
<a href="https://github.com/Metaswitch/calico/commit/4ecaf3568af52ef9cc29662a3b94672540056f05" rel="noreferrer" target="_blank">https://github.com/Metaswitch/calico/commit/4ecaf3568af52ef9cc29662a3b94672540056f05</a><br>
<br>
But still it seems a shame if this is needed.<br>
<br>
        Neil<span class=""><br>
<br>
<br>
On 07/07/15 22:32, Kevin Benton wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
How often does this happen? Is it on every call? If not, is it possible<br>
the forking logic in require_state is messing up the DB handle when it's<br>
invoked?<br>
<br>
One way to make sure there aren't open transactions for testing is to<br>
just remove the "subtransactions=True" statement from update_port in the<br>
ML2 plugin.<br>
<br>
On Jul 7, 2015 8:33 AM, "Neil Jerram" <<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a><br></span><span class="">
<mailto:<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a>>> wrote:<br>
<br>
    Thanks, Kevin, but I believe we're already doing what you advise;<br>
    please see<br>
    <a href="https://github.com/Metaswitch/calico/blob/master/calico/openstack/mech_calico.py#L346-348" rel="noreferrer" target="_blank">https://github.com/Metaswitch/calico/blob/master/calico/openstack/mech_calico.py#L346-348</a><br>
<br>
    Is there a way of checking that there aren't still any open<br>
    transactions, when update_port_postcommit is called?<br>
<br>
    Thanks,<br>
             Neil<br>
<br>
<br>
    On 07/07/15 15:57, Kevin Benton wrote:<br>
<br>
        It sounds like something is starting a transaction before calling<br>
        update_port on the core plugin. This will prevent the<br>
        transaction from<br>
        being completely closed even though ML2 is in the post_commit phase.<br>
<br>
        In your db.get_port call, make sure you are using the same DB<br>
        session<br>
        from the context that was passed into update_port_postcommit and<br>
        that<br>
        will make sure you always have access to the current state even<br>
        if the<br>
        transaction isn't closed.<br>
<br>
        On Tue, Jul 7, 2015 at 5:35 AM, Neil Jerram<br>
        <<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a> <mailto:<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a>><br></span>
        <mailto:<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a><div><div class="h5"><br>
        <mailto:<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a>>>> wrote:<br>
<br>
             I think there's something I'm not understanding about how<br>
        Neutron's<br>
             DB tables are related, and when one can safely read<br>
             believed-to-be-committed information from them...<br>
<br>
             My project's mechanism driver is handling a port update in<br>
        which the<br>
             fixed IPs are changing; specifically, a second fixed IP has<br>
        been<br>
             added to the port.  It does this (for a reason I can explain if<br>
             needed) by calling db.get_port(), in the<br>
        update_port_postcommit hook.<br>
<br>
             But we observe that the result of db.get_port() does not<br>
        include the<br>
             new fixed IP.  Even though we're in the postcommit hook,<br>
        and hence<br>
             we assume that all the changes for that port have by now<br>
        been committed.<br>
<br>
             What are we misunderstanding here?  My guess is that this is<br>
             something to do with 'fixed_ips' not being a column<br>
        directly in the<br>
             Ports table, but instead calculated from relationships<br>
        between the<br>
             port ID and another (IPAllocation) table.  We've seen a similar<br>
             problem in the past with binding:host_id, for which the same is<br>
             true, i.e. info is in the separate portbindings table.<br>
<br>
             Or could it be that the transaction hasn't really been<br>
        closed yet,<br>
             when update_port_postcommit hook is called?<br>
<br>
             (This is with Icehouse-level code, so it could be something<br>
        that's<br>
             been fixed...)<br>
<br>
             Many thanks,<br>
                      Neil<br>
<br>
<br>
        __________________________________________________________________________<br>
             OpenStack Development Mailing List (not for usage questions)<br>
             Unsubscribe:<br>
        <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
        <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
<br>
        <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
        <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
        --<br>
        Kevin Benton<br>
<br>
<br>
        __________________________________________________________________________<br>
        OpenStack Development Mailing List (not for usage questions)<br>
        Unsubscribe:<br>
        <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br></div></div>
        <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><span class=""><br>
        <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
    __________________________________________________________________________<br>
    OpenStack Development Mailing List (not for usage questions)<br>
    Unsubscribe:<br>
    <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br></span>
    <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><span class=""><br>
    <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</span></blockquote><div class="HOEnZb"><div class="h5">
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>