[openstack-dev] [neutron] out-of-tree l3 service providers

Isaku Yamahata isaku.yamahata at gmail.com
Fri Sep 8 06:04:28 UTC 2017


On Fri, Sep 08, 2017 at 12:26:56PM +0900,
Takashi Yamamoto <yamamoto at midokura.com> wrote:

> hi,
> 
> On Fri, Sep 8, 2017 at 5:52 AM, Isaku Yamahata <isaku.yamahata at gmail.com> wrote:
> > Hi.
> >
> > Any update on this? Now L3 service provider got the time slot at the PTG.
> >
> > Yamamoto, do you have any proposal for the interface?
> 
> no
> 
> > Although ODL surely is interested in L3 flavor, the networking-odl team hasn't
> > spec or experimental patch yet unfortunately.
> 
> can you at least provide your requirements?

Sure.

networking-odl needs PRECOMMIT/AFTER_CREATE/UPDATE/DELETE for
router/floaringip and PRECOMMIT for disassociate_floatingip.
The reason why precommit_disassociate_floatingip is needed is that
right now ODL doesn't support to updating floatingip status by ODL.
So floatingip status is forcibly set to DOWN by the callback for now.
(It's in future roadmap)
networking-odl doesn't need callback for add/remove_router_interface because
only db operation does. ODL identifies router interface by port:owner which is
updated by update_port.

Thanks,

> networking-midonet needs to send the following info to its backend on
> AFTER_CREATE/AFTER_UPDATE for router, router_interface, and
> floating_ip.
> https://github.com/midonet/midonet/blob/fcc127f5c9216b7a563c89d2684461428feb9a67/nsdb/src/main/proto/neutron.proto#L129-L161
> (some of fields are actually unused right now. eg. tenant_id)
> on AFTER_DELETE, we only need "id" field of the resource.
> in feature we want to use PRECOMMIT_xxx events as well. necessary
> fields are same as AFTER_xxx.
> 
> > Dragon flow folks seems to have their own spec.
> >
> > thanks,
> >
> > On Mon, Jul 31, 2017 at 02:10:07PM +0900,
> > Takashi Yamamoto <yamamoto at midokura.com> wrote:
> >
> >> hi,
> >>
> >> On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton <kevin at benton.pub> wrote:
> >> > If I understand the main issue with using regular callbacks, it's mainly
> >> > just that the flavor assignment itself is in a callback, right?
> >>
> >> yes.
> >>
> >> >
> >> > If so, couldn't we solve the problem by just moving flavor assignment to an
> >> > explicit call before emitting the callbacks? Or would that still result in
> >> > other ordering issues?
> >>
> >> it would solve the problem for CREATE.
> >> for UPDATE and DELETE, i'm not sure.
> >> UPDATE can change the flavor but it's supposed to be a special case
> >> only for dvr/ha, right?
> >> AFTER_DELETE might be tricky as we probably need to provide flavor
> >> info to subscribers.
> >>
> >> >
> >> > On Thu, Jul 13, 2017 at 3:01 AM, Takashi Yamamoto <yamamoto at midokura.com>
> >> > wrote:
> >> >>
> >> >> hi,
> >> >>
> >> >> today i managed to play with l3 flavors.
> >> >> i wrote a crude patch to implement midonet flavor. [1]
> >> >>
> >> >> [1] https://review.openstack.org/#/c/483174/
> >> >>
> >> >> a good news is it's somehow working.
> >> >>
> >> >> a bad news is it has a lot of issues, as you can see in TODO comments
> >> >> in the patch.
> >> >> given these issues, now i tend to think it's cleaner to introduce
> >> >> ml2-like precommit/postcommit driver api (or its equivalent via
> >> >> callbacks) rather than using these existing notifications.
> >> >>
> >> >> how do you think?
> >> >
> >> >
> >>
> >> __________________________________________________________________________
> >> 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
> >
> > --
> > Isaku Yamahata <isaku.yamahata at gmail.com>

-- 
Isaku Yamahata <isaku.yamahata at gmail.com>



More information about the OpenStack-dev mailing list