settingsLogin | Registersettings

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

0 votes

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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Sep 8, 2017 in openstack-dev by Takashi_Yamamoto (4,400 points)   2 3

5 Responses

0 votes

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 yamamoto@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 23, 2017 by kevin_at_benton.pub (15,600 points)   2 3 4
0 votes

hi,

On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton kevin@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 31, 2017 by Takashi_Yamamoto (4,400 points)   2 3
0 votes

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 yamamoto@midokura.com wrote:

hi,

On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton kevin@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Isaku Yamahata isaku.yamahata@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 7, 2017 by Isaku_Yamahata (2,480 points)   2 3
0 votes

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

hi,

On Fri, Sep 8, 2017 at 5:52 AM, Isaku Yamahata isaku.yamahata@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/AFTERCREATE/UPDATE/DELETE for
router/floaringip and PRECOMMIT for disassociate
floatingip.
The reason why precommitdisassociatefloatingip 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/removerouterinterface 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
AFTERCREATE/AFTERUPDATE for router, routerinterface, 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. tenantid)
on AFTER
DELETE, we only need "id" field of the resource.
in feature we want to use PRECOMMITxxx 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@midokura.com wrote:

hi,

On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton kevin@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Isaku Yamahata isaku.yamahata@gmail.com

--
Isaku Yamahata isaku.yamahata@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 8, 2017 by Isaku_Yamahata (2,480 points)   2 3
0 votes

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.yamahata@gmail.com
wrote:

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

hi,

On Fri, Sep 8, 2017 at 5:52 AM, Isaku Yamahata isaku.yamahata@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/AFTERCREATE/UPDATE/DELETE for
router/floaringip and PRECOMMIT for disassociate
floatingip.
The reason why precommitdisassociatefloatingip 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/removerouterinterface
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
AFTERCREATE/AFTERUPDATE for router, routerinterface, 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. tenantid)
on AFTER
DELETE, we only need "id" field of the resource.
in feature we want to use PRECOMMITxxx 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@midokura.com wrote:

hi,

On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton kevin@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@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@lists.openstack.org?subject:
unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Isaku Yamahata isaku.yamahata@gmail.com

--
Isaku Yamahata isaku.yamahata@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 8, 2017 by kevin_at_benton.pub (15,600 points)   2 3 4
...