<div dir="ltr">Please add the requirements underneath the l3 flavors section of the etherpad so we can come up with a plan during the PTG.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 7, 2017 at 11:04 PM, Isaku Yamahata <span dir="ltr"><<a href="mailto:isaku.yamahata@gmail.com" target="_blank">isaku.yamahata@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Sep 08, 2017 at 12:26:56PM +0900,<br>
<span class="">Takashi Yamamoto <<a href="mailto:yamamoto@midokura.com">yamamoto@midokura.com</a>> wrote:<br>
<br>
> hi,<br>
><br>
</span><span class="">> On Fri, Sep 8, 2017 at 5:52 AM, Isaku Yamahata <<a href="mailto:isaku.yamahata@gmail.com">isaku.yamahata@gmail.com</a>> wrote:<br>
> > Hi.<br>
> ><br>
> > Any update on this? Now L3 service provider got the time slot at the PTG.<br>
> ><br>
> > Yamamoto, do you have any proposal for the interface?<br>
><br>
> no<br>
><br>
> > Although ODL surely is interested in L3 flavor, the networking-odl team hasn't<br>
> > spec or experimental patch yet unfortunately.<br>
><br>
> can you at least provide your requirements?<br>
<br>
</span>Sure.<br>
<br>
networking-odl needs PRECOMMIT/AFTER_CREATE/UPDATE/<wbr>DELETE for<br>
router/floaringip and PRECOMMIT for disassociate_floatingip.<br>
The reason why precommit_disassociate_<wbr>floatingip is needed is that<br>
right now ODL doesn't support to updating floatingip status by ODL.<br>
So floatingip status is forcibly set to DOWN by the callback for now.<br>
(It's in future roadmap)<br>
networking-odl doesn't need callback for add/remove_router_interface because<br>
only db operation does. ODL identifies router interface by port:owner which is<br>
updated by update_port.<br>
<br>
Thanks,<br>
<div class="HOEnZb"><div class="h5"><br>
> networking-midonet needs to send the following info to its backend on<br>
> AFTER_CREATE/AFTER_UPDATE for router, router_interface, and<br>
> floating_ip.<br>
> <a href="https://github.com/midonet/midonet/blob/fcc127f5c9216b7a563c89d2684461428feb9a67/nsdb/src/main/proto/neutron.proto#L129-L161" rel="noreferrer" target="_blank">https://github.com/midonet/<wbr>midonet/blob/<wbr>fcc127f5c9216b7a563c89d2684461<wbr>428feb9a67/nsdb/src/main/<wbr>proto/neutron.proto#L129-L161</a><br>
> (some of fields are actually unused right now. eg. tenant_id)<br>
> on AFTER_DELETE, we only need "id" field of the resource.<br>
> in feature we want to use PRECOMMIT_xxx events as well. necessary<br>
> fields are same as AFTER_xxx.<br>
><br>
> > Dragon flow folks seems to have their own spec.<br>
> ><br>
> > thanks,<br>
> ><br>
> > On Mon, Jul 31, 2017 at 02:10:07PM +0900,<br>
> > Takashi Yamamoto <<a href="mailto:yamamoto@midokura.com">yamamoto@midokura.com</a>> wrote:<br>
> ><br>
> >> hi,<br>
> >><br>
> >> On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton <kevin@benton.pub> wrote:<br>
> >> > If I understand the main issue with using regular callbacks, it's mainly<br>
> >> > just that the flavor assignment itself is in a callback, right?<br>
> >><br>
> >> yes.<br>
> >><br>
> >> ><br>
> >> > If so, couldn't we solve the problem by just moving flavor assignment to an<br>
> >> > explicit call before emitting the callbacks? Or would that still result in<br>
> >> > other ordering issues?<br>
> >><br>
> >> it would solve the problem for CREATE.<br>
> >> for UPDATE and DELETE, i'm not sure.<br>
> >> UPDATE can change the flavor but it's supposed to be a special case<br>
> >> only for dvr/ha, right?<br>
> >> AFTER_DELETE might be tricky as we probably need to provide flavor<br>
> >> info to subscribers.<br>
> >><br>
> >> ><br>
> >> > On Thu, Jul 13, 2017 at 3:01 AM, Takashi Yamamoto <<a href="mailto:yamamoto@midokura.com">yamamoto@midokura.com</a>><br>
> >> > wrote:<br>
> >> >><br>
> >> >> hi,<br>
> >> >><br>
> >> >> today i managed to play with l3 flavors.<br>
> >> >> i wrote a crude patch to implement midonet flavor. [1]<br>
> >> >><br>
> >> >> [1] <a href="https://review.openstack.org/#/c/483174/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/483174/</a><br>
> >> >><br>
> >> >> a good news is it's somehow working.<br>
> >> >><br>
> >> >> a bad news is it has a lot of issues, as you can see in TODO comments<br>
> >> >> in the patch.<br>
> >> >> given these issues, now i tend to think it's cleaner to introduce<br>
> >> >> ml2-like precommit/postcommit driver api (or its equivalent via<br>
> >> >> callbacks) rather than using these existing notifications.<br>
> >> >><br>
> >> >> how do you think?<br>
> >> ><br>
> >> ><br>
> >><br>
> >> ______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
> ><br>
> > --<br>
> > Isaku Yamahata <<a href="mailto:isaku.yamahata@gmail.com">isaku.yamahata@gmail.com</a>><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Isaku Yamahata <<a href="mailto:isaku.yamahata@gmail.com">isaku.yamahata@gmail.com</a>><br>
</font></span></blockquote></div><br></div>