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

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

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.

Hi, everyone Can we move forward to start a vote for the GNT project if no more question? Thanks and BR, Kaiyuan

Yes, actually we hope GRPC could be a common library of ODL. It could be used as north-bound channel as well. 原始邮件 发件人： <ecelgp@...>; 收件人：宦林英10042773; 抄送人：

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?

We plan to take netconf protocol as configuration channel, GRPC just for data plane. 原始邮件 发件人： <ecelgp@...>; 收件人：宦林英10042773; 抄送人： <project-proposals@...>;

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

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

Hi, An Ho and everyone I think we can move forward if no more discussion about the GNT project.

Hello Huan Linying, 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

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

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

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

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)

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.

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

If triemap was in infrautils, could the feature itself be stable independently of the other utils in the module? Sadly, the original scope was too limited. It should have had a wider scope to cover

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. Controller

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