Cluster Metrics project proposal
|
Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES@Cisco) <dmalacho@...>
Hi,
We would like to submit proposal for new project called Cluster Metrics.
https://wiki.opendaylight.org/view/Project_Proposals:Cluster_Metrics
If we don’t need whole two weeks for public comments, we can discuss this proposal on TSC meeting next Thursday, 3rd November. Otherwise, feel free to change the date.
We are planning this project to be Offset 2.
Thank You
Daniel Malachovsky
|
|
|
|
Alexis de Talhouët <adetalhouet@...>
This is reminding me what we have started in controller project with this patch: https://git.opendaylight.org/gerrit/#/c/36751/ adding CLI to gather info/stats about data broker and cluster, reading beans.
toggle quoted message
Show quoted text
Wondering if this project is mostly about a DLUX app, or you intend to create APIs that will be consumable by the world. Also, wondering whether controller/md-sal projects should provide such APIs, or if those APIs should be provided in a separated project. Anyway, the UI is appealing. Thanks for putting this up Daniel, can’t wait for the TSC review, where we will certainly discuss some of the wonders I’m having :) Alexis
|
|
|
|
Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES@Cisco) <dmalacho@...>
HI Alexis,
This project is mainly about UI, but I think, we can make APIs consumable to everybody, why not?
dano
From: Alexis de Talhouët [mailto:adetalhouet@...]
Sent: 26. októbra 2016 23:01 To: Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) Cc: project-proposals@...; Jan Medved (jmedved); Chris Metz (chmetz); Stanislav Jamrich -X (sjamrich - PANTHEON TECHNOLOGIES at Cisco) Subject: Re: [Project-proposals] Cluster Metrics project proposal
This is reminding me what we have started in controller project with this patch: https://git.opendaylight.org/gerrit/#/c/36751/ adding CLI to gather info/stats about data broker and cluster, reading beans. Wondering if this project is mostly about a DLUX app, or you intend to create APIs that will be consumable by the world. Also, wondering whether controller/md-sal projects should provide such APIs, or if those APIs should be provided in a separated project.
Anyway, the UI is appealing.
Thanks for putting this up Daniel, can’t wait for the TSC review, where we will certainly discuss some of the wonders I’m having :)
Alexis
|
|
|
|
Colin Dixon
The 2-week public comment period is pretty much set in stone, sadly. However allowing the project to join the Carbon release is something the TSC has more authority to address and I don't think it will be an issue. Would you be able to do a review on 11/10? --ColinOn Wed, Oct 26, 2016 at 12:11 PM, Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) <dmalacho@...> wrote:
|
|
|
|
Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES@Cisco) <dmalacho@...>
No problem, we’ll be there. Thanks
dano
From: Colin Dixon [mailto:colin@...]
Sent: 27. októbra 2016 16:51 To: Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) Cc: project-proposals@...; Jan Medved (jmedved); Chris Metz (chmetz); Stanislav Jamrich -X (sjamrich - PANTHEON TECHNOLOGIES at Cisco) Subject: Re: [Project-proposals] Cluster Metrics project proposal
The 2-week public comment period is pretty much set in stone, sadly. However allowing the project to join the Carbon release is something the TSC has more authority to address and I don't think it will be an issue. Would you be able to do a review on 11/10? --Colin
On Wed, Oct 26, 2016 at 12:11 PM, Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) <dmalacho@...> wrote: Hi,
We would like to submit proposal for new project called Cluster Metrics.
https://wiki.opendaylight.org/view/Project_Proposals:Cluster_Metrics
If we don’t need whole two weeks for public comments, we can discuss this proposal on TSC meeting next Thursday, 3rd November. Otherwise, feel free to change the date.
We are planning this project to be Offset 2.
Thank You
Daniel Malachovsky
|
|
|
|
Colin Dixon
For what it's worth, it seemed like Abhijit, Alexis, and I all felt like it would be worth seriously considering having this code be contributed as new parts of the controller and dluxapps projects instead of a new project. That be said, the new project was approved, so you can and should do what you feel is right. My personal take on why is pretty simple: we have seen lots of new projects that were small in scope and had the goal of "doing one thing and doing one thing well" and then had decreased interest followed by falling behind and not only no longer contributing the value they hoped, but actually becoming a burden on our release process despite the best of intentions.Robert argued that we don't want to be adding anything to controller, but that rings exceptionally hollow to me. Either we declare controller dead and create the projects we need to house the live code or we admit that controller is live for the parts we care about (including clustering) and take contributions like a healthy project should. Jan seemed to think that the stats collected being beyond just the clustering means it needs it's own project. I can see that argument, but I don't see a huge reason why that means it can't be housed in controller. Anyway, as I said above, it's in your hands, but I wanted to take the time to lay out my concerns. On Wed, Oct 26, 2016 at 3:11 PM, Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) <dmalacho@...> wrote:
|
|
|
|
Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES@Cisco) <vrpolak@...>
System Metrics project consists of two components: the backend (Stats Reflector) and the frontend (GUI). The two components communicate using a protocol (Restconf RPCs),
When the project is young, I think it makes sense to keep both parts in the same repo. It makes it easier to alter the protocol (Yang modules).
Only when the protocol is finalized, it makes sense to move the components to umbrella projects for maintenance. GUI will obviously fit right into dluxapps project, There would be several options for Stats Reflector home: TSDR, Infrautils, Integration/Distribution, Controller.
Vratko.
From: project-proposals-bounces@... [mailto:project-proposals-bounces@...]
On Behalf Of Colin Dixon
Sent: 10 November, 2016 20:11 To: Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) <dmalacho@...> Cc: Stanislav Jamrich -X (sjamrich - PANTHEON TECHNOLOGIES at Cisco) <sjamrich@...>; project-proposals@...; Jan Medved (jmedved) <jmedved@...>; Chris Metz (chmetz) <chmetz@...> Subject: Re: [Project-proposals] Cluster Metrics project proposal
For what it's worth, it seemed like Abhijit, Alexis, and I all felt like it would be worth seriously considering having this code be contributed as new parts of the controller and dluxapps projects instead of a new project. That be said, the new project was approved, so you can and should do what you feel is right. My personal take on why is pretty simple: we have seen lots of new projects that were small in scope and had the goal of "doing one thing and doing one thing well" and then had decreased interest followed by falling behind and not only no longer contributing the value they hoped, but actually becoming a burden on our release process despite the best of intentions. If the project instead ties into a broader umbrella as part of another project, at least simple things like patches that fix version numbers and other minor-but-critical things will have a broader pool of committers to draw from to keep things moving. Obviously, there is some trade-off in that people my not be as experienced with the code, but in this case that seems unlikely since it's code the very much seems in line with existing controller/clustering code and dluxapps. Robert argued that we don't want to be adding anything to controller, but that rings exceptionally hollow to me. Either we declare controller dead and create the projects we need to house the live code or we admit that controller is live for the parts we care about (including clustering) and take contributions like a healthy project should. Jan seemed to think that the stats collected being beyond just the clustering means it needs it's own project. I can see that argument, but I don't see a huge reason why that means it can't be housed in controller. Anyway, as I said above, it's in your hands, but I wanted to take the time to lay out my concerns.
--Colin
On Wed, Oct 26, 2016 at 3:11 PM, Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) <dmalacho@...> wrote:
|
|
|
|
Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES@Cisco) <dmalacho@...>
We are thinking the same.
Our goal is to publish it, gather some feedback, make the apps better and then, if needed, split it to other projects.
dano
From: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
Sent: 11. novembra 2016 15:39 To: Colin Dixon; Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) Cc: Stanislav Jamrich -X (sjamrich - PANTHEON TECHNOLOGIES at Cisco); project-proposals@...; Jan Medved (jmedved); Chris Metz (chmetz) Subject: RE: [Project-proposals] Cluster Metrics project proposal
System Metrics project consists of two components: the backend (Stats Reflector) and the frontend (GUI). The two components communicate using a protocol (Restconf RPCs),
When the project is young, I think it makes sense to keep both parts in the same repo. It makes it easier to alter the protocol (Yang modules).
Only when the protocol is finalized, it makes sense to move the components to umbrella projects for maintenance. GUI will obviously fit right into dluxapps project, There would be several options for Stats Reflector home: TSDR, Infrautils, Integration/Distribution, Controller.
Vratko.
From:
project-proposals-bounces@... [mailto:project-proposals-bounces@...]
On Behalf Of Colin Dixon
For what it's worth, it seemed like Abhijit, Alexis, and I all felt like it would be worth seriously considering having this code be contributed as new parts of the controller and dluxapps projects instead of a new project. That be said, the new project was approved, so you can and should do what you feel is right. My personal take on why is pretty simple: we have seen lots of new projects that were small in scope and had the goal of "doing one thing and doing one thing well" and then had decreased interest followed by falling behind and not only no longer contributing the value they hoped, but actually becoming a burden on our release process despite the best of intentions. If the project instead ties into a broader umbrella as part of another project, at least simple things like patches that fix version numbers and other minor-but-critical things will have a broader pool of committers to draw from to keep things moving. Obviously, there is some trade-off in that people my not be as experienced with the code, but in this case that seems unlikely since it's code the very much seems in line with existing controller/clustering code and dluxapps. Robert argued that we don't want to be adding anything to controller, but that rings exceptionally hollow to me. Either we declare controller dead and create the projects we need to house the live code or we admit that controller is live for the parts we care about (including clustering) and take contributions like a healthy project should. Jan seemed to think that the stats collected being beyond just the clustering means it needs it's own project. I can see that argument, but I don't see a huge reason why that means it can't be housed in controller. Anyway, as I said above, it's in your hands, but I wanted to take the time to lay out my concerns.
--Colin
On Wed, Oct 26, 2016 at 3:11 PM, Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) <dmalacho@...> wrote:
|
|
|