Please add the requirements underneath the l3 flavors section of the etherpad so we can come up with a plan during the PTG.
On Thu, Sep 7, 2017 at 11:04 PM, Isaku Yamahata <isaku.yamah...@gmail.com> wrote: > On Fri, Sep 08, 2017 at 12:26:56PM +0900, > Takashi Yamamoto <yamam...@midokura.com> wrote: > > > hi, > > > > On Fri, Sep 8, 2017 at 5:52 AM, Isaku Yamahata <isaku.yamah...@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/fcc127f5c9216b7a563c89d2684461 > 428feb9a67/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 <yamam...@midokura.com> wrote: > > > > > >> hi, > > >> > > >> On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton <ke...@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 < > yamam...@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-requ...@lists.openstack.org?subject: > unsubscribe > > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > > > Isaku Yamahata <isaku.yamah...@gmail.com> > > -- > Isaku Yamahata <isaku.yamah...@gmail.com> >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev