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

[Kevin Benton]

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 
wrote:

> On Fri, Sep 08, 2017 at 12:26:56PM +0900,
> Takashi Yamamoto  wrote:
>
> > hi,
> >
> > On Fri, Sep 8, 2017 at 5:52 AM, Isaku Yamahata 
> 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  wrote:
> > >
> > >> hi,
> > >>
> > >> On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton 
> 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 Yamahata 
>
__
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

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

[Isaku Yamahata]

On Fri, Sep 08, 2017 at 12:26:56PM +0900,
Takashi Yamamoto  wrote:

> hi,
> 
> On Fri, Sep 8, 2017 at 5:52 AM, Isaku Yamahata  
> 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  wrote:
> >
> >> hi,
> >>
> >> On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton  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 
> >> > 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 Yamahata 

__
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

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

[Takashi Yamamoto]

hi,

On Fri, Sep 8, 2017 at 5:52 AM, Isaku Yamahata  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?

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  wrote:
>
>> hi,
>>
>> On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton  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 
>> > 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 

__
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

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

[Isaku Yamahata]

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?
Although ODL surely is interested in L3 flavor, the networking-odl team hasn't
spec or experimental patch yet unfortunately.
Dragon flow folks seems to have their own spec.

thanks,

On Mon, Jul 31, 2017 at 02:10:07PM +0900,
Takashi Yamamoto  wrote:

> hi,
> 
> On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton  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 
> > 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 

__
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

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

[Takashi Yamamoto]

hi,

On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton  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 
> 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

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

[Kevin Benton]

If I understand the main issue with using regular callbacks, it's mainly
just that the flavor assignment itself is in a callback, right?

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?

On Thu, Jul 13, 2017 at 3:01 AM, Takashi Yamamoto 
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

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

[Takashi Yamamoto]

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