Date   

Re: [OpenDaylight TSC] 答复: Re: New project proposal - telemetry

huan.linying@...
 

Hello folks,

I think we prefer to do the creation review of Telemetry project with email. Could we start it right now, and schedule the voting 2 weeks later?


原始邮件
发件人:宦林英10042773
收件人: <ecelgp@...>;
抄送人: <tsc@...>; <project-proposals@...>;
日 期 :2017年11月09日 13:46
主 题 :[OpenDaylight TSC] 答复: Re:  New project proposal - telemetry


Yes, actually we hope  GRPC could be a common library of ODL. It could be used as north-bound channel as well.



发件人: <ecelgp@...>;
收件人:宦林英10042773;
抄送人: <project-proposals@...>; <tsc@...>;
日 期 :2017年11月09日 11:33
主 题 :Re: [OpenDaylight TSC] New project proposal - telemetry


So I guess you will use existing netconf plugin in ODL + new GRPC. For this last will you coordinate with P4 project to reuse libraries/code?


On Nov 8, 2017, at 7:33 PM, <huan.linying@...> <huan.linying@...> wrote:

We plan to take netconf protocol as configuration channel, GRPC just for data plane.




发件人: <ecelgp@...>;
收件人:宦林英10042773;
抄送人: <project-proposals@...>; <tsc@...>;
日 期 :2017年11月09日 11:14
主 题 :Re: [OpenDaylight TSC] New project proposal - telemetry


Hi, I am curious about the control/configuration channel transport protocol: is this GRPC based too? or netconf? or restconf? or just any protocol supporting openconfig models.

BR/Luis

On Nov 6, 2017, at 12:07 AM, huan.linying@... wrote:

Hi folks,

I'd like to propose telemetry, a new device run-time information channel,  as a new project of OpenDaylight. The proposal  link is:

https://wiki.opendaylight.org/view/Project_Proposals:Telemetry


Please review the proposal and Look forward your feedback.


Thanks.

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc



Re: [OpenDaylight TSC] Start the creationreviewfor GNT

Vivek Srivastava V <vivek.v.srivastava@...>
 

Hi Sam, All,

 

I have checked GNT details again, and found that actually there is no overlap with GENIUS. It appears that the focus of GNT is mainly on monitoring and analytics, and it does not intend to perform any southbound rendering/data-plane programming for application services (NetVirt/SCF), which GENIUS does. GNT team can confirm this.

With this understanding, from my side it would be a ‘go’ for GNT.

 

Regards,

Vivek

From: Sam Hague [mailto:shague@...]
Sent: Wednesday, November 15, 2017 8:18 PM
To:
凯元; Dayavanti Gopal Kamath; Vivek Srivastava V
Cc: colin; An Ho; Xingjun Chu; tsc; project-proposals
Subject: Re: Re: [Project-proposals] [OpenDaylight TSC] Start the creationreviewfor GNT

 

Including Daya and Vivek S on this thread. I believe there were some questions regarding overlap with the Genius project. It would be good to wait until they confirm that.

 

On Wed, Nov 15, 2017 at 3:07 AM, 凯元 <duankaiyuan@...> wrote:

Hi, everyone

    

    Can we move forward to start a vote for the GNT project if no more question?

 

Thanks and BR,

Kaiyuan

 

    

 

----邮件原文----
发件人:"凯元" <duankaiyuan@...>
收件人:An Ho  <An.Ho@...>,Xingjun Chu  <Xingjun.Chu@...>,Sam Hague  <shague@...>
抄 送: tsc  <tsc@...>,project-proposals  <project-proposals@...>
发送时间:2017-11-09 08:43:51
题:Re: [Project-proposals] [OpenDaylight TSC] Start the creationreviewfor GNT

 

Hi, An Ho and everyone

 

    I think we can move forward if no more discussion about the GNT project.

 

----邮件原文----
发件人:An Ho  <An.Ho@...>
收件人:Xingjun Chu  <Xingjun.Chu@...>,Sam Hague  <shague@...>,"凯元" <duankaiyuan@...>
抄 送: project-proposals  <project-proposals@...>,tsc <tsc@...>
发送时间:2017-11-03 01:31:37
题:RE: [OpenDaylight TSC] [Project-proposals] Start the creationreview for GNT

    

As per the TSC call today, reviving this email thread with the hopes of getting additional feedback from folks.

 

Best Regards,

An Ho

 

 

From: Xingjun Chu
Sent: Tuesday, September 19, 2017 8:36 AM
To: An Ho <An.Ho@...>; Sam Hague <shague@...>;
段凯元 <duankaiyuan@...>
Cc: project-proposals <project-proposals@...>; tsc <tsc@...>
Subject: RE: [OpenDaylight TSC] [Project-proposals] Start the creation review for GNT

 

Thanks An. 

 

To GNT team,

I just quickly read through the GNT proposal.

 A few comments .  If the project only provides an unified view of the topology and track the changes of the topology across different vendor devices, it is going  to be very complementary to FaaS since FaaS is more focus on the abstraction of the topology and provides logical network services over the abstracted topology.

But In the scope, it also states “At present, the logical network of this project is based on the implementation of neutron, features can also  be extended if ODL users have other logical network models. “,

Sounds GNT also provides services on top of the topo and wondering what services it provides, if it provides Neutron like L2/L3 services as the quote above implies, then that seems overlaps with FaaS goal in some degree.

Thanks
Xingjun

 

From: An Ho
Sent: Monday, September 18, 2017 4:59 PM
To: Sam Hague <shague@...>;
段凯元 <duankaiyuan@...>; Xingjun Chu <Xingjun.Chu@...>
Cc: project-proposals <project-proposals@...>; tsc <tsc@...>
Subject: RE: [OpenDaylight TSC] [Project-proposals] Start the creation review for GNT

 

+Adding FAAS Mailing List

 

It would be great to see some cross project discussion and collaboration in this area, especially if there may exist some potential overlap.

 

Best Regards,

An Ho

 

 

From: tsc-bounces@... [mailto:tsc-bounces@...] On Behalf Of Sam Hague
Sent: Monday, September 18, 2017 12:23 PM
To:
凯元
Cc: project-proposals; tsc
Subject: Re: [OpenDaylight TSC] [Project-proposals] Start the creation review for GNT

 

Was there any discussions on how GNT compares to FaaS [1]? They seem similar in scope and seems like we had a similar discussion about scope overlap when FaaS was proposed.

 

Also would GNT use the TTP project or something similar?

 

 

On Sun, Sep 17, 2017 at 9:25 PM, 凯元 <duankaiyuan@...>  wrote:

Hi, everyone

 

What is the result of your vote for the proposal and what's the next step?

 

 

Thanks,

Kaiyuan

 

----邮件原文----
发件人:Colin Dixon  <colin@...>
收件人:"凯元" <duankaiyuan@...>
抄 送: tsc  <tsc@...>,project-proposals  <project-proposals@...>,"杨红伟" <yanghongwei@...>,dongwenying  <dongwenying@...>,"沈肖" <shenxiao@...>
发送时间:2017-09-07 22:56:30
题:Re: [Project-proposals] Start the creation review for GNT

 

Here is the proposal: https://wiki.opendaylight.org/view/Project_Proposals:General_Network_Topology

 

Previous discussion can be found here:

 

I'll plan to close discussion here on September 13th, so that we can try to vote by the September 14th TSC meeting and record the result there.

 

Please ask any more questions you have.

 

Thanks,

--Colin

 

 

On Mon, Sep 4, 2017 at 10:20 PM, 凯元 <duankaiyuan@...>  wrote:


Hi, everyone

 

I think we are ready, let's start the creation review for GNT through email. 

 

Please feel free to ask any questionsAnd I have already cc all committers.

 

 

Kaiyuan

 
_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals

 


_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals

 

 

 


Re: [OpenDaylight TSC] Start the creationreviewfor GNT

Sam Hague
 

Including Daya and Vivek S on this thread. I believe there were some questions regarding overlap with the Genius project. It would be good to wait until they confirm that.

On Wed, Nov 15, 2017 at 3:07 AM, 段凯元 <duankaiyuan@...> wrote:

Hi, everyone

    

    Can we move forward to start a vote for the GNT project if no more question?


Thanks and BR,

Kaiyuan


    

 
----邮件原文----
发件人:"段凯元" <duankaiyuan@chinamobile.com>
收件人:An Ho  <An.Ho@...>,Xingjun Chu  <Xingjun.Chu@huawei.com>,Sam Hague  <shague@redhat.com>
抄 送: tsc  <tsc@....org>,project-proposals  <project-proposals@lists.opendaylight.org>
发送时间:2017-11-09 08:43:51
主题:Re: [Project-proposals] [OpenDaylight TSC] Start the creationreviewfor GNT


Hi, An Ho and everyone


    I think we can move forward if no more discussion about the GNT project.

 
----邮件原文----
发件人:An Ho  <An.Ho@...>
收件人:Xingjun Chu  <Xingjun.Chu@huawei.com>,Sam Hague  <shague@redhat.com>,"段凯元" <duankaiyuan@...>
抄 送: project-proposals  <project-proposals@....org>,tsc <tsc@lists.opendaylight.org>
发送时间:2017-11-03 01:31:37
主题:RE: [OpenDaylight TSC] [Project-proposals] Start the creationreview for GNT

    

As per the TSC call today, reviving this email thread with the hopes of getting additional feedback from folks.

 

Best Regards,

An Ho

 

 

From: Xingjun Chu
Sent: Tuesday, September 19, 2017 8:36 AM
To: An Ho <An.Ho@...>; Sam Hague <shague@...>;
段凯元 <duankaiyuan@...>
Cc: project-proposals <project-proposals@lists.opendaylight.org>; tsc <tsc@...>
Subject: RE: [OpenDaylight TSC] [Project-proposals] Start the creation review for GNT

 

Thanks An. 

 

To GNT team,

I just quickly read through the GNT proposal.

 A few comments .  If the project only provides an unified view of the topology and track the changes of the topology across different vendor devices, it is going  to be very complementary to FaaS since FaaS is more focus on the abstraction of the topology and provides logical network services over the abstracted topology.

But In the scope, it also states “At present, the logical network of this project is based on the implementation of neutron, features can also  be extended if ODL users have other logical network models. “,

Sounds GNT also provides services on top of the topo and wondering what services it provides, if it provides Neutron like L2/L3 services as the quote above implies, then that seems overlaps with FaaS goal in some degree.

Thanks
Xingjun

 

From: An Ho
Sent: Monday, September 18, 2017 4:59 PM
To: Sam Hague <shague@...>;
段凯元 <duankaiyuan@...>; Xingjun Chu <Xingjun.Chu@...>
Cc: project-proposals <project-proposals@lists.opendaylight.org>; tsc <tsc@...>
Subject: RE: [OpenDaylight TSC] [Project-proposals] Start the creation review for GNT

 

+Adding FAAS Mailing List

 

It would be great to see some cross project discussion and collaboration in this area, especially if there may exist some potential overlap.

 

Best Regards,

An Ho

 

 

From: tsc-bounces@lists.opendaylight.org [mailto:tsc-bounces@lists.opendaylight.org] On Behalf Of Sam Hague
Sent: Monday, September 18, 2017 12:23 PM
To:
凯元
Cc: project-proposals; tsc
Subject: Re: [OpenDaylight TSC] [Project-proposals] Start the creation review for GNT

 

Was there any discussions on how GNT compares to FaaS [1]? They seem similar in scope and seems like we had a similar discussion about scope overlap when FaaS was proposed.

 

Also would GNT use the TTP project or something similar?

 

 

On Sun, Sep 17, 2017 at 9:25 PM, 凯元 <duankaiyuan@...>  wrote:

Hi, everyone

 

What is the result of your vote for the proposal and what's the next step?

 

 

Thanks,

Kaiyuan

 

----邮件原文----
发件人:Colin Dixon  <colin@colindixon.com>
收件人:"凯元" <duankaiyuan@chinamobile.com>
抄 送: tsc  <tsc@....org>,project-proposals  <project-proposals@lists.opendaylight.org>,"杨红伟" <yanghongwei@...>,dongwenying  <dongwenying@chinamobile.com>,"沈肖" <shenxiao@...>
发送时间:2017-09-07 22:56:30
题:Re: [Project-proposals] Start the creation review for GNT

 

Here is the proposal: https://wiki.opendaylight.org/view/Project_Proposals:General_Network_Topology

 

Previous discussion can be found here:

 

I'll plan to close discussion here on September 13th, so that we can try to vote by the September 14th TSC meeting and record the result there.

 

Please ask any more questions you have.

 

Thanks,

--Colin

 

 

On Mon, Sep 4, 2017 at 10:20 PM, 凯元 <duankaiyuan@...>  wrote:


Hi, everyone

 

I think we are ready, let's start the creation review for GNT through email. 

 

Please feel free to ask any questionsAnd I have already cc all committers.

 

 

Kaiyuan

 
_______________________________________________
project-proposals mailing list
project-proposals@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/project-proposals

 


_______________________________________________
project-proposals mailing list
project-proposals@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/project-proposals

 




Re: [OpenDaylight TSC] Start the creationreviewfor GNT

Kaiyuan Duan
 

Hi, everyone

    

    Can we move forward to start a vote for the GNT project if no more question?


Thanks and BR,

Kaiyuan


    

 

----邮件原文----
发件人:"段凯元" <duankaiyuan@...>
收件人:An Ho  <An.Ho@...>,Xingjun Chu  <Xingjun.Chu@...>,Sam Hague  <shague@...>
抄 送: tsc  <tsc@...>,project-proposals  <project-proposals@...>
发送时间:2017-11-09 08:43:51
主题:Re: [Project-proposals] [OpenDaylight TSC] Start the creationreviewfor GNT

Hi, An Ho and everyone


    I think we can move forward if no more discussion about the GNT project.

 
----邮件原文----
发件人:An Ho  <An.Ho@...>
收件人:Xingjun Chu  <Xingjun.Chu@...>,Sam Hague  <shague@...>,"段凯元" <duankaiyuan@...>
抄 送: project-proposals  <project-proposals@...>,tsc <tsc@...>
发送时间:2017-11-03 01:31:37
主题:RE: [OpenDaylight TSC] [Project-proposals] Start the creationreview for GNT

    

As per the TSC call today, reviving this email thread with the hopes of getting additional feedback from folks.

 

Best Regards,

An Ho

 

 

From: Xingjun Chu
Sent: Tuesday, September 19, 2017 8:36 AM
To: An Ho <An.Ho@...>; Sam Hague <shague@...>;
段凯元 <duankaiyuan@...>
Cc: project-proposals <project-proposals@...>; tsc <tsc@...>
Subject: RE: [OpenDaylight TSC] [Project-proposals] Start the creation review for GNT

 

Thanks An. 

 

To GNT team,

I just quickly read through the GNT proposal.

 A few comments .  If the project only provides an unified view of the topology and track the changes of the topology across different vendor devices, it is going  to be very complementary to FaaS since FaaS is more focus on the abstraction of the topology and provides logical network services over the abstracted topology.

But In the scope, it also states “At present, the logical network of this project is based on the implementation of neutron, features can also  be extended if ODL users have other logical network models. “,

Sounds GNT also provides services on top of the topo and wondering what services it provides, if it provides Neutron like L2/L3 services as the quote above implies, then that seems overlaps with FaaS goal in some degree.

Thanks
Xingjun

 

From: An Ho
Sent: Monday, September 18, 2017 4:59 PM
To: Sam Hague <shague@...>;
段凯元 <duankaiyuan@...>; Xingjun Chu <Xingjun.Chu@...>
Cc: project-proposals <project-proposals@...>; tsc <tsc@...>
Subject: RE: [OpenDaylight TSC] [Project-proposals] Start the creation review for GNT

 

+Adding FAAS Mailing List

 

It would be great to see some cross project discussion and collaboration in this area, especially if there may exist some potential overlap.

 

Best Regards,

An Ho

 

 

From: tsc-bounces@... [mailto:tsc-bounces@...] On Behalf Of Sam Hague
Sent: Monday, September 18, 2017 12:23 PM
To:
凯元
Cc: project-proposals; tsc
Subject: Re: [OpenDaylight TSC] [Project-proposals] Start the creation review for GNT

 

Was there any discussions on how GNT compares to FaaS [1]? They seem similar in scope and seems like we had a similar discussion about scope overlap when FaaS was proposed.

 

Also would GNT use the TTP project or something similar?

 

 

On Sun, Sep 17, 2017 at 9:25 PM, 凯元 <duankaiyuan@...>  wrote:

Hi, everyone

 

What is the result of your vote for the proposal and what's the next step?

 

 

Thanks,

Kaiyuan

 

----邮件原文----
发件人:Colin Dixon  <colin@...>
收件人:"凯元" <duankaiyuan@...>
抄 送: tsc  <tsc@...>,project-proposals  <project-proposals@...>,"杨红伟" <yanghongwei@...>,dongwenying  <dongwenying@...>,"沈肖" <shenxiao@...>
发送时间:2017-09-07 22:56:30
题:Re: [Project-proposals] Start the creation review for GNT

 

Here is the proposal: https://wiki.opendaylight.org/view/Project_Proposals:General_Network_Topology

 

Previous discussion can be found here:

 

I'll plan to close discussion here on September 13th, so that we can try to vote by the September 14th TSC meeting and record the result there.

 

Please ask any more questions you have.

 

Thanks,

--Colin

 

 

On Mon, Sep 4, 2017 at 10:20 PM, 凯元 <duankaiyuan@...>  wrote:


Hi, everyone

 

I think we are ready, let's start the creation review for GNT through email. 

 

Please feel free to ask any questionsAnd I have already cc all committers.

 

 

Kaiyuan

 
_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals

 


_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals

 



Re: 答复: Re: [OpenDaylight TSC] New project proposal - telemetry

huan.linying@...
 

Yes, actually we hope  GRPC could be a common library of ODL. It could be used as north-bound channel as well.


原始邮件
发件人: <ecelgp@...>;
收件人:宦林英10042773;
抄送人: <project-proposals@...>; <tsc@...>;
日 期 :2017年11月09日 11:33
主 题 :Re: [OpenDaylight TSC] New project proposal - telemetry


So I guess you will use existing netconf plugin in ODL + new GRPC. For this last will you coordinate with P4 project to reuse libraries/code?


On Nov 8, 2017, at 7:33 PM, <huan.linying@...> <huan.linying@...> wrote:

We plan to take netconf protocol as configuration channel, GRPC just for data plane.




发件人: <ecelgp@...>;
收件人:宦林英10042773;
抄送人: <project-proposals@...>; <tsc@...>;
日 期 :2017年11月09日 11:14
主 题 :Re: [OpenDaylight TSC] New project proposal - telemetry


Hi, I am curious about the control/configuration channel transport protocol: is this GRPC based too? or netconf? or restconf? or just any protocol supporting openconfig models.

BR/Luis

On Nov 6, 2017, at 12:07 AM, huan.linying@... wrote:

Hi folks,

I'd like to propose telemetry, a new device run-time information channel,  as a new project of OpenDaylight. The proposal  link is:

https://wiki.opendaylight.org/view/Project_Proposals:Telemetry


Please review the proposal and Look forward your feedback.


Thanks.

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc



Re: [OpenDaylight TSC] New project proposal - telemetry

Luis Gomez
 

So I guess you will use existing netconf plugin in ODL + new GRPC. For this last will you coordinate with P4 project to reuse libraries/code?


On Nov 8, 2017, at 7:33 PM, <huan.linying@...> <huan.linying@...> wrote:

We plan to take netconf protocol as configuration channel, GRPC just for data plane.


原始邮件
发件人: <ecelgp@...>;
收件人:宦林英10042773;
抄送人: <project-proposals@...>; <tsc@...>;
日 期 :2017年11月09日 11:14
主 题 :Re: [OpenDaylight TSC] New project proposal - telemetry


Hi, I am curious about the control/configuration channel transport protocol: is this GRPC based too? or netconf? or restconf? or just any protocol supporting openconfig models.

BR/Luis

On Nov 6, 2017, at 12:07 AM, huan.linying@... wrote:

Hi folks,

I'd like to propose telemetry, a new device run-time information channel,  as a new project of OpenDaylight. The proposal  link is:

https://wiki.opendaylight.org/view/Project_Proposals:Telemetry


Please review the proposal and Look forward your feedback.


Thanks.

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc




Re: 答复: Re: [OpenDaylight TSC] New project proposal - telemetry

huan.linying@...
 

We plan to take netconf protocol as configuration channel, GRPC just for data plane.


原始邮件
发件人: <ecelgp@...>;
收件人:宦林英10042773;
抄送人: <project-proposals@...>; <tsc@...>;
日 期 :2017年11月09日 11:14
主 题 :Re: [OpenDaylight TSC] New project proposal - telemetry


Hi, I am curious about the control/configuration channel transport protocol: is this GRPC based too? or netconf? or restconf? or just any protocol supporting openconfig models.

BR/Luis

On Nov 6, 2017, at 12:07 AM, huan.linying@... wrote:

Hi folks,

I'd like to propose telemetry, a new device run-time information channel,  as a new project of OpenDaylight. The proposal  link is:

https://wiki.opendaylight.org/view/Project_Proposals:Telemetry


Please review the proposal and Look forward your feedback.


Thanks.

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc



Re: [OpenDaylight TSC] New project proposal - telemetry

Luis Gomez
 

Hi, I am curious about the control/configuration channel transport protocol: is this GRPC based too? or netconf? or restconf? or just any protocol supporting openconfig models.

BR/Luis

On Nov 6, 2017, at 12:07 AM, huan.linying@... wrote:

Hi folks,

I'd like to propose telemetry, a new device run-time information channel,  as a new project of OpenDaylight. The proposal  link is:

https://wiki.opendaylight.org/view/Project_Proposals:Telemetry


Please review the proposal and Look forward your feedback.


Thanks.

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc


Re: [OpenDaylight TSC] New project proposal - telemetry

huan.linying@...
 

Hi Michael,

Thanks for your infomation about infrautils.metrics. which is  a very helpful util. 


In my opinion, telemetry does not overlap with metrics. 

Metrics focus on how java code works, it gives an "inner sight" of java code, sucn as how many times the api has been called, how many time a func costs. It will be very helpful in sw performance optimization work. 

Telemetry has a much wider scope, You can report any data with any program language,  for example cpu usage, memory useage, NIC statistics. User just need to define a data model.  An example is you can even report a sepecific packet forwarding delay with P4 language. If the device could report metric data, I think it is good to have metrics as a channel of telemetry.


As we know, the carriers are looking forward a new channel to collect system state from different kinds of devices, to support their new requirements, such as AI management. And we believe telemetry will be a good choice.


Thanks.


原始邮件
发件人: <vorburger@...>;
收件人:宦林英10042773;
抄送人: <project-proposals@...>; <tsc@...>; <afredette@...>; <vivek.v.srivastava@...>;
日 期 :2017年11月08日 21:09
主 题 :Re: [OpenDaylight TSC] New project proposal - telemetry


Hello Huan Linying,

On Mon, Nov 6, 2017 at 9:07 AM,  <huan.linying@...> wrote:

Hi folks,

I'd like to propose telemetry, a new device run-time information channel,  as a new project of OpenDaylight. The proposal  link is:

https://wiki.opendaylight.org/view/Project_Proposals:Telemetry

Please review the proposal and Look forward your feedback.

several people have pointed out to me that I should let you know about upcoming https://jira.opendaylight.org/browse/INFRAUTILS-19.

This post is a pure FYI. I have no opinion pro or con your project proposal - best of luck! (Perhaps your Telemetry project, if it gets accepted, wants to later build on top of infrautils.metrics - that's up to you. FYI infrautils.metrics will stay very simple and low-level.)

Tx,
M.
--
Michael Vorburger, Red Hat
vorburger@... | IRC: vorburger @freenode | ~ = http://vorburger.ch
 

Thanks.


_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc




Re: [OpenDaylight TSC] Start the creationreview for GNT

Kaiyuan Duan
 

Hi, An Ho and everyone


    I think we can move forward if no more discussion about the GNT project.

 

----邮件原文----
发件人:An Ho  <An.Ho@...>
收件人:Xingjun Chu  <Xingjun.Chu@...>,Sam Hague  <shague@...>,"段凯元" <duankaiyuan@...>
抄 送: project-proposals  <project-proposals@...>,tsc <tsc@...>
发送时间:2017-11-03 01:31:37
主题:RE: [OpenDaylight TSC] [Project-proposals] Start the creationreview for GNT

   

As per the TSC call today, reviving this email thread with the hopes of getting additional feedback from folks.

 

Best Regards,

An Ho

 

 

From: Xingjun Chu
Sent: Tuesday, September 19, 2017 8:36 AM
To: An Ho <An.Ho@...>; Sam Hague <shague@...>;
段凯元 <duankaiyuan@...>
Cc: project-proposals <project-proposals@...>; tsc <tsc@...>
Subject: RE: [OpenDaylight TSC] [Project-proposals] Start the creation review for GNT

 

Thanks An. 

 

To GNT team,

I just quickly read through the GNT proposal.

 A few comments .  If the project only provides an unified view of the topology and track the changes of the topology across different vendor devices, it is going  to be very complementary to FaaS since FaaS is more focus on the abstraction of the topology and provides logical network services over the abstracted topology.

But In the scope, it also states “At present, the logical network of this project is based on the implementation of neutron, features can also  be extended if ODL users have other logical network models. “,

Sounds GNT also provides services on top of the topo and wondering what services it provides, if it provides Neutron like L2/L3 services as the quote above implies, then that seems overlaps with FaaS goal in some degree.

Thanks
Xingjun

 

From: An Ho
Sent: Monday, September 18, 2017 4:59 PM
To: Sam Hague <shague@...>;
段凯元 <duankaiyuan@...>; Xingjun Chu <Xingjun.Chu@...>
Cc: project-proposals <project-proposals@...>; tsc <tsc@...>
Subject: RE: [OpenDaylight TSC] [Project-proposals] Start the creation review for GNT

 

+Adding FAAS Mailing List

 

It would be great to see some cross project discussion and collaboration in this area, especially if there may exist some potential overlap.

 

Best Regards,

An Ho

 

 

From: tsc-bounces@... [mailto:tsc-bounces@...] On Behalf Of Sam Hague
Sent: Monday, September 18, 2017 12:23 PM
To:
凯元
Cc: project-proposals; tsc
Subject: Re: [OpenDaylight TSC] [Project-proposals] Start the creation review for GNT

 

Was there any discussions on how GNT compares to FaaS [1]? They seem similar in scope and seems like we had a similar discussion about scope overlap when FaaS was proposed.

 

Also would GNT use the TTP project or something similar?

 

 

On Sun, Sep 17, 2017 at 9:25 PM, 凯元 <duankaiyuan@...>  wrote:

Hi, everyone

 

What is the result of your vote for the proposal and what's the next step?

 

 

Thanks,

Kaiyuan

 

----邮件原文----
发件人:Colin Dixon  <colin@...>
收件人:"凯元" <duankaiyuan@...>
抄 送: tsc  <tsc@...>,project-proposals  <project-proposals@...>,"杨红伟" <yanghongwei@...>,dongwenying  <dongwenying@...>,"沈肖" <shenxiao@...>
发送时间:2017-09-07 22:56:30
题:Re: [Project-proposals] Start the creation review for GNT

 

Here is the proposal: https://wiki.opendaylight.org/view/Project_Proposals:General_Network_Topology

 

Previous discussion can be found here:

 

I'll plan to close discussion here on September 13th, so that we can try to vote by the September 14th TSC meeting and record the result there.

 

Please ask any more questions you have.

 

Thanks,

--Colin

 

 

On Mon, Sep 4, 2017 at 10:20 PM, 凯元 <duankaiyuan@...>  wrote:


Hi, everyone

 

I think we are ready, let's start the creation review for GNT through email. 

 

Please feel free to ask any questionsAnd I have already cc all committers.

 

 

Kaiyuan

 
_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals

 


_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals

 


Re: [OpenDaylight TSC] New project proposal - telemetry

Michael Vorburger <vorburger@...>
 

Hello Huan Linying,

On Mon, Nov 6, 2017 at 9:07 AM, <huan.linying@...> wrote:

Hi folks,

I'd like to propose telemetry, a new device run-time information channel,  as a new project of OpenDaylight. The proposal  link is:

https://wiki.opendaylight.org/view/Project_Proposals:Telemetry

Please review the proposal and Look forward your feedback.

several people have pointed out to me that I should let you know about upcoming https://jira.opendaylight.org/browse/INFRAUTILS-19.

This post is a pure FYI. I have no opinion pro or con your project proposal - best of luck! (Perhaps your Telemetry project, if it gets accepted, wants to later build on top of infrautils.metrics - that's up to you. FYI infrautils.metrics will stay very simple and low-level.)

Tx,
M.
--
Michael Vorburger, Red Hat
vorburger@... | IRC: vorburger @freenode | ~ = http://vorburger.ch
 

Thanks.


_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc



New project proposal - telemetry

huan.linying@...
 

Hi folks,

I'd like to propose telemetry, a new device run-time information channel,  as a new project of OpenDaylight. The proposal  link is:

https://wiki.opendaylight.org/view/Project_Proposals:Telemetry


Please review the proposal and Look forward your feedback.


Thanks.


Re: [OpenDaylight TSC] Start the creation review for GNT

an.ho@huawei.com
 

As per the TSC call today, reviving this email thread with the hopes of getting additional feedback from folks.

 

Best Regards,

An Ho

 

 

From: Xingjun Chu
Sent: Tuesday, September 19, 2017 8:36 AM
To: An Ho <An.Ho@...>; Sam Hague <shague@...>;
段凯元 <duankaiyuan@...>
Cc: project-proposals <project-proposals@...>; tsc <tsc@...>
Subject: RE: [OpenDaylight TSC] [Project-proposals] Start the creation review for GNT

 

Thanks An. 

 

To GNT team,

I just quickly read through the GNT proposal.

 A few comments .  If the project only provides an unified view of the topology and track the changes of the topology across different vendor devices, it is going to be very complementary to FaaS since FaaS is more focus on the abstraction of the topology and provides logical network services over the abstracted topology.

But In the scope, it also states “At present, the logical network of this project is based on the implementation of neutron, features can also be extended if ODL users have other logical network models. “,

Sounds GNT also provides services on top of the topo and wondering what services it provides, if it provides Neutron like L2/L3 services as the quote above implies, then that seems overlaps with FaaS goal in some degree.

Thanks
Xingjun

 

From: An Ho
Sent: Monday, September 18, 2017 4:59 PM
To: Sam Hague <shague@...>;
段凯元 <duankaiyuan@...>; Xingjun Chu <Xingjun.Chu@...>
Cc: project-proposals <project-proposals@...>; tsc <tsc@...>
Subject: RE: [OpenDaylight TSC] [Project-proposals] Start the creation review for GNT

 

+Adding FAAS Mailing List

 

It would be great to see some cross project discussion and collaboration in this area, especially if there may exist some potential overlap.

 

Best Regards,

An Ho

 

 

From: tsc-bounces@... [mailto:tsc-bounces@...] On Behalf Of Sam Hague
Sent: Monday, September 18, 2017 12:23 PM
To:
凯元
Cc: project-proposals; tsc
Subject: Re: [OpenDaylight TSC] [Project-proposals] Start the creation review for GNT

 

Was there any discussions on how GNT compares to FaaS [1]? They seem similar in scope and seems like we had a similar discussion about scope overlap when FaaS was proposed.

 

Also would GNT use the TTP project or something similar?

 

 

On Sun, Sep 17, 2017 at 9:25 PM, 凯元 <duankaiyuan@...> wrote:

Hi, everyone

 

What is the result of your vote for the proposal and what's the next step?

 

 

Thanks,

Kaiyuan

 

----邮件原文----
发件人:Colin Dixon  <colin@...>
收件人:"凯元" <duankaiyuan@...>
抄 送: tsc  <tsc@...>,project-proposals  <project-proposals@...>,"杨红伟" <yanghongwei@...>,dongwenying  <dongwenying@...>,"沈肖" <shenxiao@...>
发送时间:2017-09-07 22:56:30
题:Re: [Project-proposals] Start the creation review for GNT

 

Here is the proposal: https://wiki.opendaylight.org/view/Project_Proposals:General_Network_Topology

 

Previous discussion can be found here:

 

I'll plan to close discussion here on September 13th, so that we can try to vote by the September 14th TSC meeting and record the result there.

 

Please ask any more questions you have.

 

Thanks,

--Colin

 

 

On Mon, Sep 4, 2017 at 10:20 PM, 凯元 <duankaiyuan@...> wrote:


Hi, everyone

 

I think we are ready, let's start the creation review for GNT through email. 

 

Please feel free to ask any questionsAnd I have already cc all committers.

 

 

Kaiyuan

 
_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals

 


_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals

 


Re: [OpenDaylight TSC] Start the creationreview for GNT

xingjun chu
 

Hi Hongwei,

 

That’s awesome. Based on your explanation I think we are not conflicting each other, but also complementary.  I am looking forward to cooperating between FaaS and GNT  more on the future.

 

Thanks!

Xingjun

 

From: yanghongwei [mailto:yanghongwei@...]
Sent: Wednesday, November 01, 2017 11:44 PM
To: Xingjun Chu <Xingjun.Chu@...>
Cc: duankaiyuan <duankaiyuan@...>; dongwenying <dongwenying@...>
Subject: Fw: Re: [OpenDaylight TSC] [Project-proposals] Start the creationreview for GNT

 

Xingjun,你好!

 

前段时间我们在ODL立一个项目:GNT,针对你提出的是否和FssS重复的疑问,我们做了下面分析,最终认为GNTFssS是不同的,如有任何疑问,可邮件或电话联系,谢谢。

 

对比了FaaSGNT的各自实现,差异总结:

1GNT只关注整网拓扑,FaaS不只关注拓扑,还提供统一的北向配置接口;

2GNT利用已有网络元素显示网络拓扑,包括overlay网络和underlay网络,并同步跟踪两种网络拓扑的变化,FaaS的拓扑中的网络单元是自定义的;

 

 

具体实现如下:

FaaS

目的:

因为没有对物理网络的抽象,像GBPNIC这种以应用为中心的项目配置物理网络非常困难,造成应用程序的南向配置接口绑定,结构单一、容易出错、难以维护;

 

实现方案:

FaaS将物理网络抽象为一个fabric,每个fabric提供公共网络服务,包括L2 / L3连接、QoS以及ACL控件,并向北向提供统一抽象接口,GBP这些应用程序直接配置fabric,不是直接配置物理网络,减少以应用为中心的应用(如GPB)和物理网络的耦合。

 

具体实现:

FaaS定义了下面基本抽象网络模型以及对它们的北向操作(抽象的北向接口)

 

·     * logical switch

·     * gateway

·     * logical router

·     * Tunnel between logical switch and logical router

·     * ACL

 

利用这些模型可以将物理网络抽象成一个或多个fabric网络模型,例如:

FaaS

上面物理网络抽象成下面逻辑拓扑:

 

Fabric

 

注:FaaS目前只支持GBP作为北向接口以及OVSDB / OPENFLOW / Openvswitch作为南向接口

 

GNT

目的:

针对有软件OVS、硬件交换机、第三方设备等多种南向设备混合部署场景,当南向资源有增加或删除变化时,业务应用要对每一类物理网络资源的拓扑变化分别监听和维护,逻辑复杂,占用过多资源。

 

实现方案:

提供南向设备统一网络拓扑,包括overlay网络拓扑和underlay网络拓扑,业务应用只需要监听GNT内容,就能得到南向设备的增删改查操作动态以及网络拓扑变化,applications只需要关注业务逻辑本身,不需要监听每类南向资源的变化,优化了数据监听流程。

 

具体实现:

GNT定义新的yang模型,对多个不同类型的南向资源模型进行抽象,通过监听南向资源的配置数据展现网络整体的拓扑视图,跟踪拓扑变化。

 

注:GNT仅提供南向设备网络拓扑信息,applications如需对南向设备配置,仍需要直接对接各个设备的北向接口,GNT不像FaaS将拓扑进行抽象提供统一的北向配置接口。

 

 


杨红伟

中国移动通信研究院/China Mobile Research Institute

Email: yanghongwei@...

Tel: +86 15801642577

     +86 15801696688-35027

----邮件原文----
发件人:Xingjun Chu  <Xingjun.Chu@...>
收件人:An Ho  <An.Ho@...>,Sam Hague  <shague@...>,"段凯元" <duankaiyuan@...>
抄 送:    project-proposals  <project-proposals@...>,tsc <tsc@...>
发送时间:2017-09-19    23:36:27
主题:RE: [OpenDaylight TSC] [Project-proposals] Start the creationreview for GNT

      

Thanks    An. 

 

To    GNT team,

I    just quickly read through the GNT proposal.

 A    few comments .  If the project only provides an unified view of the    topology and track the changes of the topology across different vendor    devices, it is going to be very complementary  to FaaS since FaaS is more    focus on the abstraction of the topology and provides logical network services    over the abstracted topology.

But    In the scope, it also states “At present, the logical    network of this project is based on the implementation of neutron, features    can also be extended  if ODL users have other logical network models. “,    

Sounds GNT also provides services on top of the topo and    wondering what services it provides, if it provides Neutron like L2/L3    services as the quote above implies, then that seems overlaps with FaaS goal    in some degree.

Thanks
Xingjun

 

From: An Ho    
Sent: Monday, September 18, 2017 4:59    PM
To: Sam Hague <shague@...>;
段凯元    <duankaiyuan@...>; Xingjun Chu    <Xingjun.Chu@...>
Cc: project-proposals    <project-proposals@...>; tsc    <tsc@...>
Subject: RE:    [OpenDaylight TSC] [Project-proposals] Start the creation review for    GNT

 

+Adding    FAAS Mailing List

 

It    would be great to see some cross project discussion and collaboration in this    area, especially if there may exist some potential overlap.

 

Best    Regards,

An    Ho

 

 

From: tsc-bounces@...    [mailto:tsc-bounces@...]    On Behalf Of Sam Hague
Sent: Monday,    September 18, 2017 12:23 PM
To:
凯元
Cc:    project-proposals; tsc
Subject: Re: [OpenDaylight TSC]    [Project-proposals] Start the creation review for GNT

 

Was there any discussions on how GNT compares to FaaS [1]?    They seem similar in scope and seems like we had a similar discussion about    scope overlap when FaaS was proposed.

 

Also would GNT use the TTP project or something  similar?

 

 

On Sun, Sep 17, 2017 at 9:25 PM, 凯元 <duankaiyuan@...> wrote:

Hi, everyone

 

What is the result of your vote for the proposal and what's the next    step?

 

 

Thanks,

Kaiyuan

 

----邮件原文----
发件人:Colin Dixon  <colin@...>
收件人:"凯元" <duankaiyuan@...>
抄 送: tsc  <tsc@...>,project-proposals  <project-proposals@...>,"杨红伟" <yanghongwei@...>,dongwenying  <dongwenying@...>,"沈肖" <shenxiao@...>
发送时间:2017-09-07      22:56:30
题:Re: [Project-proposals] Start the creation review for GNT

 

Here is the proposal: https://wiki.opendaylight.org/view/Project_Proposals:General_Network_Topology

 

Previous discussion can be found here:

 

I'll plan to close discussion here on September 13th, so      that we can try to vote by the September 14th TSC meeting and record the      result there.

 

Please ask any more questions you have.

 

Thanks,

--Colin

 

 

On Mon, Sep 4, 2017 at 10:20 PM, 凯元 <duankaiyuan@...> wrote:


Hi, everyone

 

I think we are ready, let's start the creation review for GNT through      email. 

 

Please feel free to ask any questionsAnd I have already cc all      committers.

 

 

Kaiyuan


_______________________________________________
project-proposals      mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals

 


_______________________________________________
project-proposals    mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals

 

 


Re: [OpenDaylight TSC] A new project proposal: TrieMap

Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES@Cisco) <vrpolak@...>
 

If triemap was in infrautils, could the feature itself be stable
independently of the other utils in the module?
The karaf feature could be marked as stable,
The feature could be marked as a stable API [3].

But for being marked as Stable (with capital S) [2],
(among other things) Infrautils would need to be
Mature (as opposed to Incubation) project.

Vratko.

[2] https://wiki.opendaylight.org/view/Simultaneous_Release:Nitrogen_Release_Plan#Stable_and_Extended_Features
[3] https://wiki.opendaylight.org/view/Simultaneous_Release:Nitrogen_Release_Plan#APIs

-----Original Message-----
From: tsc-bounces@... [mailto:tsc-bounces@...] On Behalf Of Robert Varga
Sent: 21 September, 2017 16:22
To: Sam Hague <shague@...>
Cc: tsc@...; project-proposals@...
Subject: Re: [OpenDaylight TSC] A new project proposal: TrieMap

On 21/09/17 15:21, Sam Hague wrote:


On Thu, Sep 21, 2017 at 4:11 AM, Robert Varga <nite@...
<mailto:nite@...>> wrote:

On 21/09/17 09:17, Anil Vishnoi wrote:
> At a high level this is the same issue that we came across with lldp
> library code and it end up moving to openflowplugin project. That
> probably was not ideal solution, but i believe comparing the trade-off
> of logistics cost of new project vs moving it to most relevant project
> made sense in that scenario.

We do have a precedent, where we split off a much smaller chunk of code
into a separate project -- tcpmd5 -- and there was essentially zero
overhead and no complications in doing that.

> Given that this code lived in yangtools till now and fairly stable code,
> also assuming that there is no downstream consumer of this code except
> yantools,

Controller does use it too, and I suspect there are other places which
could benefit from it.

> it seems reasonable to me to either keep it in yangtools or
> move it to infrautils (probably not ideal solution, but seems practical
> to me ). Given that there are only two pom.xml in this code base, not
> sure the effort spend in version bumping of this code really makes a
> strong reason for a new project (until and unless i missed something).

As I mentioned, infrautils simply does not cut it, it is nowhere near in
terms of stability.

If triemap was in infrautils, could the feature itself be stable
independently of the other utils in the module?
The karaf feature could be marked as stable, but it would still have to branch and version bump with the rest of the project -- exactly the as it has to in yangtools.

Avoiding that churn is at this moment key driver behind the proposal.

https://wiki.opendaylight.org/view/Project_Proposals:Infrastructure_Utilities#Scope
<https://wiki.opendaylight.org/view/Project_Proposals:Infrastructure_Utilities#Scope>
does not cover it, and if that really is the current scope, infrautils
is already greatly exceeding its scope.

Sadly, the original scope was too limited. It should have had a wider
scope to cover what we really wanted - which is a place to put useful
utilities that other projects can consume without the need to create a
new project.
I am not convinced that actually was necessary.

Examining current autorelease, the only beneficiary was daexim using the ready service. All other users already depend on genius, where most of the utilities existed -- hence there those utilities could have stayed in genius.

https://stackoverflow.com/questions/3305511/is-it-good-to-have-utils-class-in-your-software-project,
answers 2 (and 3) give a good summary why Utils classes are not a good thing in the long term. Having that at project level is very much the same thing.

This has been raised during discussions leading to infrautils proposal and creation review, at this point everything that looks like a semi-reusable piece of code is now considered to be in scope of infrautils.

That actually brings about the question of what our governance is
regarding re-scoping projects -- I do not believe we have the equivalent
of IETF recharter process...

We rescoped NetVirt as part of pulling OVSDB out of it. Seemed like it
was just a mini project proposal.
... which actually was reviewed and approved by the TSC. I do not believe such a thing happened with infrautils, or have I missed something?

Regards,
Robert


Re: [OpenDaylight TSC] A new project proposal: TrieMap

Sam Hague
 



On Thu, Sep 21, 2017 at 10:22 AM, Robert Varga <nite@...> wrote:
On 21/09/17 15:21, Sam Hague wrote:
>
>
> On Thu, Sep 21, 2017 at 4:11 AM, Robert Varga <nite@...
> <mailto:nite@...>> wrote:
>
>     On 21/09/17 09:17, Anil Vishnoi wrote:
>     > At a high level this is the same issue that we came across with lldp
>     > library code and it end up moving to openflowplugin project. That
>     > probably was not ideal solution, but i believe comparing the trade-off
>     > of logistics cost of new project vs moving it to most relevant project
>     > made sense in that scenario.
>
>     We do have a precedent, where we split off a much smaller chunk of code
>     into a separate project -- tcpmd5 -- and there was essentially zero
>     overhead and no complications in doing that.
>
>     > Given that this code lived in yangtools till now and fairly stable code,
>     > also assuming that there is no downstream consumer of this code except
>     > yantools,
>
>     Controller does use it too, and I suspect there are other places which
>     could benefit from it.
>
>     > it seems reasonable to me to either keep it in yangtools or
>     > move it to infrautils (probably not ideal solution, but seems practical
>     > to me ). Given that there are only two pom.xml in this code base, not
>     > sure the effort spend in version bumping of this code really makes a
>     > strong reason for a new project (until and unless i missed something).
>
>     As I mentioned, infrautils simply does not cut it, it is nowhere near in
>     terms of stability.
>
> If triemap was in infrautils, could the feature itself be stable
> independently of the other utils in the module?

The karaf feature could be marked as stable, but it would still have to
branch and version bump with the rest of the project -- exactly the as
it has to in yangtools.

Avoiding that churn is at this moment key driver behind the proposal.

>     https://wiki.opendaylight.org/view/Project_Proposals:Infrastructure_Utilities#Scope
>     <https://wiki.opendaylight.org/view/Project_Proposals:Infrastructure_Utilities#Scope>
>     does not cover it, and if that really is the current scope, infrautils
>     is already greatly exceeding its scope.
>
> Sadly, the original scope was too limited. It should have had a wider
> scope to cover what we really wanted - which is a place to put useful
> utilities that other projects can consume without the need to create a
> new project.

I am not convinced that actually was necessary.

Examining current autorelease, the only beneficiary was daexim using the
ready service. All other users already depend on genius, where most of
the utilities existed -- hence there those utilities could have stayed
in genius.

https://stackoverflow.com/questions/3305511/is-it-good-to-have-utils-class-in-your-software-project,
answers 2 (and 3) give a good summary why Utils classes are not a good
thing in the long term. Having that at project level is very much the
same thing.

This has been raised during discussions leading to infrautils proposal
and creation review, at this point everything that looks like a
semi-reusable piece of code is now considered to be in scope of infrautils.

>     That actually brings about the question of what our governance is
>     regarding re-scoping projects -- I do not believe we have the equivalent
>     of IETF recharter process...
>
> We rescoped NetVirt as part of pulling OVSDB out of it. Seemed like it
> was just a mini project proposal.

... which actually was reviewed and approved by the TSC. I do not
believe such a thing happened with infrautils, or have I missed something?
No, this has not been done. I was suggesting that if we did want to rescope then we have an example and don't need to create a process. 

Regards,
Robert



Re: [OpenDaylight TSC] A new project proposal: TrieMap

Robert Varga
 

On 21/09/17 15:21, Sam Hague wrote:


On Thu, Sep 21, 2017 at 4:11 AM, Robert Varga <nite@...
<mailto:nite@...>> wrote:

On 21/09/17 09:17, Anil Vishnoi wrote:
> At a high level this is the same issue that we came across with lldp
> library code and it end up moving to openflowplugin project. That
> probably was not ideal solution, but i believe comparing the trade-off
> of logistics cost of new project vs moving it to most relevant project
> made sense in that scenario.

We do have a precedent, where we split off a much smaller chunk of code
into a separate project -- tcpmd5 -- and there was essentially zero
overhead and no complications in doing that.

> Given that this code lived in yangtools till now and fairly stable code,
> also assuming that there is no downstream consumer of this code except
> yantools,

Controller does use it too, and I suspect there are other places which
could benefit from it.

> it seems reasonable to me to either keep it in yangtools or
> move it to infrautils (probably not ideal solution, but seems practical
> to me ). Given that there are only two pom.xml in this code base, not
> sure the effort spend in version bumping of this code really makes a
> strong reason for a new project (until and unless i missed something).

As I mentioned, infrautils simply does not cut it, it is nowhere near in
terms of stability.

If triemap was in infrautils, could the feature itself be stable
independently of the other utils in the module?
The karaf feature could be marked as stable, but it would still have to
branch and version bump with the rest of the project -- exactly the as
it has to in yangtools.

Avoiding that churn is at this moment key driver behind the proposal.

https://wiki.opendaylight.org/view/Project_Proposals:Infrastructure_Utilities#Scope
<https://wiki.opendaylight.org/view/Project_Proposals:Infrastructure_Utilities#Scope>
does not cover it, and if that really is the current scope, infrautils
is already greatly exceeding its scope.

Sadly, the original scope was too limited. It should have had a wider
scope to cover what we really wanted - which is a place to put useful
utilities that other projects can consume without the need to create a
new project.
I am not convinced that actually was necessary.

Examining current autorelease, the only beneficiary was daexim using the
ready service. All other users already depend on genius, where most of
the utilities existed -- hence there those utilities could have stayed
in genius.

https://stackoverflow.com/questions/3305511/is-it-good-to-have-utils-class-in-your-software-project,
answers 2 (and 3) give a good summary why Utils classes are not a good
thing in the long term. Having that at project level is very much the
same thing.

This has been raised during discussions leading to infrautils proposal
and creation review, at this point everything that looks like a
semi-reusable piece of code is now considered to be in scope of infrautils.

That actually brings about the question of what our governance is
regarding re-scoping projects -- I do not believe we have the equivalent
of IETF recharter process...

We rescoped NetVirt as part of pulling OVSDB out of it. Seemed like it
was just a mini project proposal.
... which actually was reviewed and approved by the TSC. I do not
believe such a thing happened with infrautils, or have I missed something?

Regards,
Robert


Re: [OpenDaylight TSC] A new project proposal: TrieMap

Sam Hague
 



On Thu, Sep 21, 2017 at 4:11 AM, Robert Varga <nite@...> wrote:
On 21/09/17 09:17, Anil Vishnoi wrote:
> At a high level this is the same issue that we came across with lldp
> library code and it end up moving to openflowplugin project. That
> probably was not ideal solution, but i believe comparing the trade-off
> of logistics cost of new project vs moving it to most relevant project
> made sense in that scenario.

We do have a precedent, where we split off a much smaller chunk of code
into a separate project -- tcpmd5 -- and there was essentially zero
overhead and no complications in doing that.

> Given that this code lived in yangtools till now and fairly stable code,
> also assuming that there is no downstream consumer of this code except
> yantools,

Controller does use it too, and I suspect there are other places which
could benefit from it.

> it seems reasonable to me to either keep it in yangtools or
> move it to infrautils (probably not ideal solution, but seems practical
> to me ). Given that there are only two pom.xml in this code base, not
> sure the effort spend in version bumping of this code really makes a
> strong reason for a new project (until and unless i missed something).

As I mentioned, infrautils simply does not cut it, it is nowhere near in
terms of stability.
If triemap was in infrautils, could the feature itself be stable independently of the other utils in the module?

I am not sure what version bumping effort you are referring to -- the
project will not participate in autorelease and given its API/ABI
stability, downstreams can easily use ranged dependency, completely
eliminating the need for version bumping procedures known from SR.

> I personally would like to move it to infrautils project, that way
> downstream projects also can leverage this implementation. If that is a
> possible option and the scope of the project is a problem then i think
> bringing that to discussion would be useful ( although looking at the
> scope of infrautils, i didn't find anything that's really blocker here).

https://wiki.opendaylight.org/view/Project_Proposals:Infrastructure_Utilities#Scope
does not cover it, and if that really is the current scope, infrautils
is already greatly exceeding its scope.
Sadly, the original scope was too limited. It should have had a wider scope to cover what we really wanted - which is a place to put useful utilities that other projects can consume without the need to create a new project. 

That actually brings about the question of what our governance is
regarding re-scoping projects -- I do not believe we have the equivalent
of IETF recharter process...
We rescoped NetVirt as part of pulling OVSDB out of it. Seemed like it was just a mini project proposal.

Regards,
Robert


_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc



Re: [OpenDaylight TSC] A new project proposal: TrieMap

Robert Varga
 

On 21/09/17 09:17, Anil Vishnoi wrote:
At a high level this is the same issue that we came across with lldp
library code and it end up moving to openflowplugin project. That
probably was not ideal solution, but i believe comparing the trade-off
of logistics cost of new project vs moving it to most relevant project
made sense in that scenario.
We do have a precedent, where we split off a much smaller chunk of code
into a separate project -- tcpmd5 -- and there was essentially zero
overhead and no complications in doing that.

Given that this code lived in yangtools till now and fairly stable code,
also assuming that there is no downstream consumer of this code except
yantools,
Controller does use it too, and I suspect there are other places which
could benefit from it.

it seems reasonable to me to either keep it in yangtools or
move it to infrautils (probably not ideal solution, but seems practical
to me ). Given that there are only two pom.xml in this code base, not
sure the effort spend in version bumping of this code really makes a
strong reason for a new project (until and unless i missed something).
As I mentioned, infrautils simply does not cut it, it is nowhere near in
terms of stability.

I am not sure what version bumping effort you are referring to -- the
project will not participate in autorelease and given its API/ABI
stability, downstreams can easily use ranged dependency, completely
eliminating the need for version bumping procedures known from SR.

I personally would like to move it to infrautils project, that way
downstream projects also can leverage this implementation. If that is a
possible option and the scope of the project is a problem then i think
bringing that to discussion would be useful ( although looking at the
scope of infrautils, i didn't find anything that's really blocker here).
https://wiki.opendaylight.org/view/Project_Proposals:Infrastructure_Utilities#Scope
does not cover it, and if that really is the current scope, infrautils
is already greatly exceeding its scope.

That actually brings about the question of what our governance is
regarding re-scoping projects -- I do not believe we have the equivalent
of IETF recharter process...

Regards,
Robert


Re: [OpenDaylight TSC] A new project proposal: TrieMap

Anil Vishnoi
 

At a high level this is the same issue that we came across with lldp library code and it end up moving to openflowplugin project. That probably was not ideal solution, but i believe comparing the trade-off of logistics cost of new project vs moving it to most relevant project made sense in that scenario.

Given that this code lived in yangtools till now and fairly stable code, also assuming that there is no downstream consumer of this code except yantools, it seems reasonable to me to either keep it in yangtools or move it to infrautils (probably not ideal solution, but seems practical to me ). Given that there are only two pom.xml in this code base, not sure the effort spend in version bumping of this code really makes a strong reason for a new project (until and unless i missed something).

I personally would like to move it to infrautils project, that way downstream projects also can leverage this implementation. If that is a possible option and the scope of the project is a problem then i think bringing that to discussion would be useful ( although looking at the scope of infrautils, i didn't find anything that's really blocker here).

On Wed, Sep 20, 2017 at 6:39 AM, Michael Vorburger <vorburger@...> wrote:
On Wed, Sep 20, 2017 at 2:47 PM, Robert Varga <nite@...> wrote:
On 20/09/17 14:10, Michael Vorburger wrote:
> On Mon, Sep 18, 2017 at 3:49 PM, Robert Varga <nite@...
> <mailto:nite@...>> wrote:
>
>     Hello everyone,
>
>     I would like to propose a new project, TrieMap, as detailed in
>     https://wiki.opendaylight.org/view/Project_Proposals:Triemap
>     <https://wiki.opendaylight.org/view/Project_Proposals:Triemap>.
>
>     This would be an Oxygen-timeframe spin-off from YANG Tools, which is
>     currently hosting the codebase due to it being the topmost project
>     requiring the implementation.
>
>     There are three reasons for splitting the code from YANG Tools:
>     - the code is outside of scope of YANG Tools
>     - the code does not have any dependencies on other code in YANG Tools
>     - the code is almost feature-complete at this stage and very stable,
>     hence would benefit from independent versioning
>
>     Please review the proposal, any feedback is welcome.
>
>
> an entire formal new ODL project for these... 5 classes strikes me as ..
> curious.

nite@nitebug : ~/odl/yangtools/third-party/triemap on  $ find . -name
\*.java | wc -l
51

 
nite@nitebug : ~/odl/yangtools/third-party/triemap on  $ find . -name
\*.java | xargs wc -l | tail -n 1
  4691 total

e.g. 51 classes for 4.7KLOC, with some small room for growth in features
(spliterators) and test coverage.

> I noticed that you have, apparently in vain, attempted to contribute to
> upstream https://github.com/romix/java-concurrent-hash-trie-map ... in
> an ideal world, that guy, whoever he is, should just make you a
> committer on that repo, but I'm guessing from seeing PRs here
> https://github.com/romix/java-concurrent-hash-trie-map/pulls ignore
> that's not going to happen? ;-)

Completely unresponsive for 18+ months.

> But so instead of a new top level ODL project how about just:
>
> (a) just keep this on your personal GitHub, release to Maven central,
> and depend on it in yangtools? This code is for a very general data
> structure, and has nothing at all to do with ODL SDN as such.

Well, I really like to keep ODL coding standards and packaging, which
means consuming odlparent -- which is not in maven central, making it
not really convenient.

> (b) just integrate this either as a new package in an existing bundle or
> as a new bundle into an existing ODL project instead of creating yet
> another one?

As noted, this is already done, as the code currently lives in
yangtools. This works, but is not ideal, as it forces unnecessary
versioning churn.

> infrautils comes to mind - personally that's what I think
> it's for (general infra structure "lower than" yangtools). I do
> understand you have some sort of reservations about infrautils, but you
> are a commmitter on it, so you are more than welcome to contribute
> whatever you think is needed in infrautils to make it suitable for
> consumption e.g. by yangtools.

Not "some sort", I have voiced my reservations very clearly multiple
times. One key factor is no bounds on scope, which is very critical for
long-term project health -- at some point a project needs to become code
complete. There is no amount of code I can contribute to fix that.

Aside from that, the codebase in question is about 40% the size of
infrautils and it has *way* better quality:

infrautils:
https://sonar.opendaylight.org/overview?id=66717

triemap:
https://sonar.opendaylight.org/overview?id=org.opendaylight.yangtools%3Atriemap

> Just my 2 cents. If others feel strongly in favour of starting to have
> many "micro" projects at the top-level in ODL, then I have no strong
> objections against that either. But then we could start doing that for
> many other bunch of 5 classes as well...

Aside from '5 classes'. I personally have no problem with that -- as
long as you can:

and that is probably the real Q here - do we want to have such "small" projects.. I'll let others make that decision!
 
- clearly define scope and stick to it, quickly converging on
feature-completeness
- provide strictly semver'd releases
- sit outside of autorelease

Regards,
Robert



_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc




--
Thanks
Anil

121 - 140 of 829