[Starlingx-discuss] Request for review of several StartlingX neutron upstream features

Zhao, Forrest forrest.zhao at intel.com
Wed Aug 8 14:26:42 UTC 2018


+ StarlingX list

From: Qin, Kailun
Sent: Friday, July 27, 2018 10:39 AM
To: Jolliffe, Ian <Ian.Jolliffe at windriver.com>
Cc: Le, Huifeng <huifeng.le at intel.com>; Qin, Kailun <kailun.qin at intel.com>; Xu, Chenjie <chenjie.xu at intel.com>; Zhao, Forrest <forrest.zhao at intel.com>; Guo, Ruijing <ruijing.guo at intel.com>; Troyer, Dean <dean.troyer at intel.com>; Jones, Bruce E <bruce.e.jones at intel.com>; Rowsell, Brent <Brent.Rowsell at windriver.com>; Peters, Matt <Matt.Peters at windriver.com>
Subject: RE: Request for review of several StartlingX neutron upstream features

Hi Ian,

Thanks a lot for the feedbacks!

The commit IDs related w/ the features cited previously are listed below.
[1] system host management: 566b640, 4aa521e, baa8264, c6849f, e6669ec
[2] router & DHCP rescheduling: 00dd7cb, 05aed14
[3] provider network management: 021ae1a

To be specific for the dependencies, we have:

1.      021ae1a[3] depends on 566b640[1], i.e. providernet management depends on system host management.

2.      566b640 etc.[1] is related w/ 00dd7cb[2], i.e. system host management is related w/ router & dhcp rescheduling and fault management (stx component).

For provider network management, the feature is great and it would be nice if we can get the community’s support to stand alone. However, based on the following facts:

1)      It brings about quite a lot new resources, DBs and new type drivers etc. which need to functionally align with the current neutron core components;

2)      It depends on system host management, while host is NOT a network attribute and host management may have some other db level and deployment level alternatives;

3)      It also relates to (re)scheduling and fault management etc.;
which might raise some community discussions.

Thus, we have also made some plan-Bs in order to better accommodate the features to the upstream in case of slow socialization progress. As mentioned in my last mail, we’ve prepared:

1)      Host bindings of provider networks: https://review.openstack.org/579410/.

2)      Dynamic segment range management of self-service networks: https://review.openstack.org/579411.

3)      Managed provider networks: a full-functionality providernet management which should support dynamic providernet add/edit + segmentation edit (based on proposal 2).

4)      Rescheduling of routers and DHCP servers: please kindly refer to the attached.

5)      Fault management: the drafted idea is to only expose interfaces in the upstream neutron, but move the reference implementation to another project like stx-fault.

6)      Host management: the drafted idea is to separate it to another standalone project if we do need that.

7)      Router & DHCP (re)scheduling will be part of 4). The host-based scheduler will be covered in 1) w/ those 2 community bugs addressed.

Let me know if any further question or anything unclear. Great thanks!

BR,
Kailun

From: Jolliffe, Ian [mailto:Ian.Jolliffe at windriver.com]
Sent: Friday, July 27, 2018 9:36 AM
To: Qin, Kailun <kailun.qin at intel.com<mailto:kailun.qin at intel.com>>
Cc: OTC NST Edge Staff <otc.nst.edge.staff at intel.com<mailto:otc.nst.edge.staff at intel.com>>; Guo, Ruijing <ruijing.guo at intel.com<mailto:ruijing.guo at intel.com>>; Troyer, Dean <dean.troyer at intel.com<mailto:dean.troyer at intel.com>>; Jones, Bruce E <bruce.e.jones at intel.com<mailto:bruce.e.jones at intel.com>>; Rowsell, Brent <Brent.Rowsell at windriver.com<mailto:Brent.Rowsell at windriver.com>>; Peters, Matt <Matt.Peters at windriver.com<mailto:Matt.Peters at windriver.com>>
Subject: Re: Request for review of several StartlingX neutron upstream features

Hi Kailun;

I don’t have access to the Intel GitHub any longer – can you provide the commit ID.  I agree we need to unravel the dependencies on the StarlingX code base in this case.  Let’s see which bits can be separated.  Can you please clarify the dependency you are identifying?

Which of these commits have dependencies on StarlingX code?

I think the Provider network management will need some socialization with the community and be able to stand alone.  This simplifies network configuration, which is a very nice usability feature.

[4] and [5] should proceed as they are bugs.

Regards;

Ian

From: "Qin, Kailun" <kailun.qin at intel.com<mailto:kailun.qin at intel.com>>
Date: Wednesday, July 25, 2018 at 5:54 AM
To: Ian Jolliffe <Ian.Jolliffe at windriver.com<mailto:Ian.Jolliffe at windriver.com>>
Cc: OTC NST Edge Staff <otc.nst.edge.staff at intel.com<mailto:otc.nst.edge.staff at intel.com>>, "Guo, Ruijing" <ruijing.guo at intel.com<mailto:ruijing.guo at intel.com>>, "Troyer, Dean" <dean.troyer at intel.com<mailto:dean.troyer at intel.com>>, "Jones, Bruce E" <bruce.e.jones at intel.com<mailto:bruce.e.jones at intel.com>>
Subject: Request for review of several StartlingX neutron upstream features

Hi Ian,

This is Kailun from NST/OTC/SSG working on the StarlingX feature upstream to OpenStack neutron.

Based on a previous analysis on the existing patches [1][2][3], we found that “provider network management”[3] has dependency on “system host management”[1]. And “system host management”[1] is also related w/ “router & DHCP rescheduling”[2] along with the StarlingX fault management. In this context, we’d like to propose the following features.
1.      For provider network management, there would be:
1.1   Host bindings of provider networks
1.2   Dynamic segment range management of self-service networks
1.3   Managed provider networks
2.      For system host management, we’ll have:
2.1   Rescheduling of routers and DHCP servers
2.2   Fault management
3.      For router & DHCP rescheduling, they will be part of (2.1). As for the host-based scheduler, we’ll make sure it is covered in (1.1), in which case the upstream DHCP/L3 scheduler can work correctly based on the host information and w/ multiple mechanism drivers by having the related bugs [4][5] fixed.

[1] system host management: 0004-host-system-host-management-extension<https://github.intel.com/Madawaska/patch-review/blob/master/neutron/0004-host-system-host-management-extension.patch>, etc.
[2] router & DHCP rescheduling: 0070-CGTS-8120-host-use-interface-bindings-for-dhcp-sched<https://github.intel.com/Madawaska/patch-review/blob/master/neutron/0070-CGTS-8120-host-use-interface-bindings-for-dhcp-sched.patch>, 0019-US75599-Introduce-rescheduling-of-routers-and-DHCP-s<https://github.intel.com/Madawaska/patch-review/blob/master/neutron/0019-US75599-Introduce-rescheduling-of-routers-and-DHCP-s.patch>, etc.
[3] provider network management: 0005-pnet-extension-to-expose-providernet-management-at-a<https://github.intel.com/Madawaska/patch-review/blob/master/neutron/0005-pnet-extension-to-expose-providernet-management-at-a.patch>
[4] https://bugs.launchpad.net/neutron/+bug/1732448
[5] https://bugs.launchpad.net/neutron/+bug/1732445

Would you please kindly help review the features proposed and provide your suggestions on their priorities?

Let me know if you have any question. Thanks a lot!

BR,
Kailun

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20180808/109df9d3/attachment-0001.html>


More information about the Starlingx-discuss mailing list