Hi, As discussed with Rico I send a mail to report the telemetry project status. We had already finished some work in Ussuri: 1.Support dynamic pollster feature Thanks Rafael Weingärtner hard working https://review.opendev.org/#/c/677031/ https://review.opendev.org/#/c/691659/ https://review.opendev.org/#/c/691944/ https://review.opendev.org/#/c/694345/ https://review.opendev.org/#/c/693088/ https://review.opendev.org/#/c/694519/ 2.Support aodh-evaluator built-in active/active deployment mode 3.Support threshold type alarm again Thanks, Lingxian https://review.opendev.org/#/c/697566/ https://review.opendev.org/#/c/695997/ Also, We plan to do some work in Ussuri: 1.Add Ceilometer API back Since Gnocchi is out of OpenStack and is unmaintained, we need to add Ceilometer API back again. 2.Mongodb database backend support As this thread [0] discuss, there are still some users still use mongodb as the database backend, we decide to add this support again. License issue should consider and fix by user. The OVH and Catalyst Cloud had fix the mongodb performance issue with some mongodb changes. Gnoochi will still support as the backed. Other database (like influxdb, ES....), we would happy everyone to submit patches to support as the database backed in ceilometer. 3.cpu_utils support This is mentioned many many times, this is a useful metric, so we decide support this again. 4.Support container meters with Zun 5. Acknowledgment of OpenStack-wide Goals I created a storyboard to track Ceilometer Ussuri release to do things in [1]. Free free to add things you want to do in Ussuri release. [0]: http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010922.... [1]: https://storyboard.openstack.org/#!/board/205 -- Thanks, Rong Zhu
On 15/12/19 10:20 pm, Rong Zhu wrote:
1.Add Ceilometer API back Since Gnocchi is out of OpenStack and is unmaintained, we need to add Ceilometer API back again.
This is concerning because even the people who wrote it don't consider it adequate to the job. That inadequacy has been the source of significant reputational damage to OpenStack in the past, and many folks (me included) are anxious to avoid a repeat. Telemetry is part of the TC "Approved Release" that is eligible for the trademark program; I think at a minimum the TC will want to remove the resurrected Ceilometer API from the "designated sections" that users are required to run to participate in any trademark program that includes the functionality in question. But I think that we should explore other ways of reducing the chance of anyone confusing this for a viable way of building a cloud, including possibly changing the name (Antediluvian API?) and having this part of the stack live outside of the official OpenStack project. I'm not clear on which parts of the API you plan to resurrect, but for example - wearing my Heat hat - after a long process of migrating Ceilometer alarm resources in Heat to Aodh ones (mostly involving breaking changes forced on us by the absence of a migration path in Telemetry), I have zero interest in turning around and going back in the other direction. I would infinitely prefer that we find a path to e.g. migrate to Monasca as the collector so that the community can speak with one voice about how to do metrics and alarming in OpenStack.
2.Mongodb database backend support As this thread [0] discuss, there are still some users still use mongodb as the database backend, we decide to add this support again. License issue should consider and fix by user.
So long as this is not the only backend available, I agree the licensing of MongoDB itself is not a concern for OpenStack (we have plenty of drivers that depend on even proprietary software in various places). The issue that Matthias alluded to in the thread is that Linux distributions are dropping MongoDB due to its non-free license, so it is not nearly as widely and easily available as it was in the past.
The OVH and Catalyst Cloud had fix the mongodb performance issue with some mongodb changes.
It's really hard to reconcile this with the information here (and especially in the linked slide): https://github.com/gnocchixyz/gnocchi/issues/1049#issuecomment-555768072
Gnoochi will still support as the backed. Other database (like influxdb, ES....), we would happy everyone to submit patches to support as the database backed in ceilometer.
This is good to hear :) cheers, Zane.
Zane Bitter wrote:
On 15/12/19 10:20 pm, Rong Zhu wrote:
1.Add Ceilometer API back Since Gnocchi is out of OpenStack and is unmaintained, we need to add Ceilometer API back again.
This is concerning because even the people who wrote it don't consider it adequate to the job. That inadequacy has been the source of significant reputational damage to OpenStack in the past, and many folks (me included) are anxious to avoid a repeat.
Yes this concerns me too, and even if we workaround the issue by adding Ceilo API back, I'd like to have a long-term plan to solve this issue. It seems there are several options on the table (including integrating Monasca and Ceilometer into a single stack, and other big-bang replacements) but it's never a one-for-one comparison as the solutions seem to address slightly disjoint problem spaces. I'd like to hear from more Ceilometer users. What are they using Ceilometer for, and what long-term plans would be acceptable. There is a trade-off between adopting short-term workarounds that reintroduce performance issues vs. undergoing a complex migration to the "right" way of fixing this. Like for example there is little point in pushing Monasca/Ceilometer stack integration if most users say, like Catalyst Cloud seems to say, that they would rather have a slow performing Ceilometer API back.
Telemetry is part of the TC "Approved Release" that is eligible for the trademark program; I think at a minimum the TC will want to remove the resurrected Ceilometer API from the "designated sections" that users are required to run to participate in any trademark program that includes the functionality in question. But I think that we should explore other ways of reducing the chance of anyone confusing this for a viable way of building a cloud, including possibly changing the name (Antediluvian API?) and having this part of the stack live outside of the official OpenStack project.
Legacy API? -- Thierry Carrez (ttx)
My present employer is just starting with Openstack and we aren't using Ceilometer yet, but when I was at eBay we had a whole team trying to make it work and it was still terrible. I was very happy when I heard that the shitty old ceilometer was going away and would never be heard from again. As an operator, I want to see a clear path forward; a path that does not include going back to something that never worked properly. If there's a choice between doing it the "right" way, and doing something easier, we all know that doing it the "right" way will be easier in the long run. -----Original Message----- From: Thierry Carrez <thierry@openstack.org> Sent: Tuesday, December 17, 2019 3:14 AM To: openstack-discuss@lists.openstack.org Subject: Re: [Telemetry][TC]Telemetry status I'd like to hear from more Ceilometer users. What are they using Ceilometer for, and what long-term plans would be acceptable. There is a trade-off between adopting short-term workarounds that reintroduce performance issues vs. undergoing a complex migration to the "right" way of fixing this. Like for example there is little point in pushing Monasca/Ceilometer stack integration if most users say, like Catalyst Cloud seems to say, that they would rather have a slow performing Ceilometer API back.
On Dec 17, 2019, at 9:03 PM, Albert Braden <Albert.Braden@synopsys.com> wrote:
My present employer is just starting with Openstack and we aren't using Ceilometer yet, but when I was at eBay we had a whole team trying to make it work and it was still terrible. I was very happy when I heard that the shitty old ceilometer was going away and would never be heard from again.
I hope the users of the services you provide never speak to you in this way. Irrespective of the accuracy of what you say, this sort of statement is poor form in a community discussion. Please have more respect for your peers in the future. Doug
On Dec 17, 2019, at 6:14 AM, Thierry Carrez <thierry@openstack.org<mailto:thierry@openstack.org>> wrote: Zane Bitter wrote: On 15/12/19 10:20 pm, Rong Zhu wrote: 1.Add Ceilometer API back Since Gnocchi is out of OpenStack and is unmaintained, we need to add Ceilometer API back again. This is concerning because even the people who wrote it don't consider it adequate to the job. That inadequacy has been the source of significant reputational damage to OpenStack in the past, and many folks (me included) are anxious to avoid a repeat. Yes this concerns me too, and even if we workaround the issue by adding Ceilo API back, I'd like to have a long-term plan to solve this issue. It seems there are several options on the table (including integrating Monasca and Ceilometer into a single stack, and other big-bang replacements) but it's never a one-for-one comparison as the solutions seem to address slightly disjoint problem spaces. I'd like to hear from more Ceilometer users. What are they using Ceilometer for, and what long-term plans would be acceptable. There is a trade-off between adopting short-term workarounds that reintroduce performance issues vs. undergoing a complex migration to the "right" way of fixing this. Like for example there is little point in pushing Monasca/Ceilometer stack integration if most users say, like Catalyst Cloud seems to say, that they would rather have a slow performing Ceilometer API back. Telemetry is part of the TC "Approved Release" that is eligible for the trademark program; I think at a minimum the TC will want to remove the resurrected Ceilometer API from the "designated sections" that users are required to run to participate in any trademark program that includes the functionality in question. But I think that we should explore other ways of reducing the chance of anyone confusing this for a viable way of building a cloud, including possibly changing the name (Antediluvian API?) and having this part of the stack live outside of the official OpenStack project. Legacy API? FWIW, telemetry projects are indeed eligible *for consideration*…but Ceilometer has never actually been required by any interop guideline: https://github.com/openstack/interop/blob/master/2019.11.json#L3218-L3222 It’s come up a few times over the years but was never deemed to have met enough of the criteria [1] to warrant inclusion in a guideline. [1] https://github.com/openstack/interop/blob/master/doc/source/process/CoreCrit... At Your Service, Mark T. Voelker -- Thierry Carrez (ttx)
On 17 Dec 2019, at 10:14 pm, Thierry Carrez <thierry@openstack.org> wrote:
Zane Bitter wrote:
On 15/12/19 10:20 pm, Rong Zhu wrote:
1.Add Ceilometer API back Since Gnocchi is out of OpenStack and is unmaintained, we need to add Ceilometer API back again. This is concerning because even the people who wrote it don't consider it adequate to the job. That inadequacy has been the source of significant reputational damage to OpenStack in the past, and many folks (me included) are anxious to avoid a repeat.
Yes this concerns me too, and even if we workaround the issue by adding Ceilo API back, I'd like to have a long-term plan to solve this issue. It seems there are several options on the table (including integrating Monasca and Ceilometer into a single stack, and other big-bang replacements) but it's never a one-for-one comparison as the solutions seem to address slightly disjoint problem spaces.
I'd like to hear from more Ceilometer users. What are they using Ceilometer for, and what long-term plans would be acceptable. There is a trade-off between adopting short-term workarounds that reintroduce performance issues vs. undergoing a complex migration to the "right" way of fixing this. Like for example there is little point in pushing Monasca/Ceilometer stack integration if most users say, like Catalyst Cloud seems to say, that they would rather have a slow performing Ceilometer API back.
Nectar Cloud has been a ceilometer user from the early days. Well we tried to be and couldn’t use it as ceilometer api and mongo db just didn’t work at our scale. Gnocchi solved all these issues for us and we use ceilometer/aodh/gnocchi happily in production for several years now. If telemetry project is going down the path of the old days it will mean we will either drop ceilometer all together and look at alternative solutions like monasca or Prometheus etc. I just can’t see how the old architecture of ceilometer is ever going to be usable. If there is some confidence that gnocchi publisher will be supported in the future we would keep using gnocchi and just maintain it ourselves. It’s an open source project and I was hoping the openstack community could keep it going. We’d be happy to help maintain it at least. We use ceilometer/gnocchi to collect and store all metrics from openstack services. We have also written some custom pollsters and gnocchi is quite flexible here to allow this. With these metrics we build reports for our users, our operators, our funders (the government) Please reconsider your direction much like adding cpu_util back in (thank you for this!) Cheers, Sam
Telemetry is part of the TC "Approved Release" that is eligible for the trademark program; I think at a minimum the TC will want to remove the resurrected Ceilometer API from the "designated sections" that users are required to run to participate in any trademark program that includes the functionality in question. But I think that we should explore other ways of reducing the chance of anyone confusing this for a viable way of building a cloud, including possibly changing the name (Antediluvian API?) and having this part of the stack live outside of the official OpenStack project.
Legacy API?
-- Thierry Carrez (ttx)
Hi all, 1. Maybe Gnocchi is good, but it's not part of OpenStack, currently there is no one in the Telemetry team shows any interest in maintaining it, I'd be very happy to see if there is someone raises hand and say: I can commit to spend some time on this project, fixing bugs, maintaining document and answering questions either on IRC or via email. If yes, We will see how it goes in this dev cycle. 2. Monasca is also good, although it doesn't support auditing i.e. storing samples which is needed by billing purpose but I didn't see it's mentioned by anyone in this thread. What's more, it introduces kafaka which is not usually used in all other openstack core services. It's up to the cloud providers for the adoption, but at least it's not in our roadmap. 3. The Telemetry team did have discussed to bring the Ceilometer API and MongoDB support back, given neither Gnocchi nor Monasca is able to store the original samples. However, nothing is happening, so don't be panic. the current project core members are also the Telemetry service cloud providers, we know how important it is to not break anything, to not bring any more overhead than before. we are so glad to see this discussion, at least there are still so many people using Ceilometer/Gnocchi and have concerns about the current upstream situation. It would be much better that people involved in this discussion could participate in the design and implementation of the future tasks. Again, thanks for all the feedback and suggestions! - Best regards, Lingxian Kong Catalyst Cloud On Wed, Dec 18, 2019 at 5:41 PM Sam Morrison <sorrison@gmail.com> wrote:
On 17 Dec 2019, at 10:14 pm, Thierry Carrez <thierry@openstack.org> wrote:
Zane Bitter wrote:
On 15/12/19 10:20 pm, Rong Zhu wrote:
1.Add Ceilometer API back Since Gnocchi is out of OpenStack and is unmaintained, we need to add Ceilometer API back again. This is concerning because even the people who wrote it don't consider it adequate to the job. That inadequacy has been the source of significant reputational damage to OpenStack in the past, and many folks (me included) are anxious to avoid a repeat.
Yes this concerns me too, and even if we workaround the issue by adding Ceilo API back, I'd like to have a long-term plan to solve this issue. It seems there are several options on the table (including integrating Monasca and Ceilometer into a single stack, and other big-bang replacements) but it's never a one-for-one comparison as the solutions seem to address slightly disjoint problem spaces.
I'd like to hear from more Ceilometer users. What are they using Ceilometer for, and what long-term plans would be acceptable. There is a trade-off between adopting short-term workarounds that reintroduce performance issues vs. undergoing a complex migration to the "right" way of fixing this. Like for example there is little point in pushing Monasca/Ceilometer stack integration if most users say, like Catalyst Cloud seems to say, that they would rather have a slow performing Ceilometer API back.
Nectar Cloud has been a ceilometer user from the early days. Well we tried to be and couldn’t use it as ceilometer api and mongo db just didn’t work at our scale. Gnocchi solved all these issues for us and we use ceilometer/aodh/gnocchi happily in production for several years now. If telemetry project is going down the path of the old days it will mean we will either drop ceilometer all together and look at alternative solutions like monasca or Prometheus etc. I just can’t see how the old architecture of ceilometer is ever going to be usable.
If there is some confidence that gnocchi publisher will be supported in the future we would keep using gnocchi and just maintain it ourselves. It’s an open source project and I was hoping the openstack community could keep it going. We’d be happy to help maintain it at least.
We use ceilometer/gnocchi to collect and store all metrics from openstack services. We have also written some custom pollsters and gnocchi is quite flexible here to allow this. With these metrics we build reports for our users, our operators, our funders (the government)
Please reconsider your direction much like adding cpu_util back in (thank you for this!)
Cheers, Sam
Telemetry is part of the TC "Approved Release" that is eligible for the
trademark program; I think at a minimum the TC will want to remove the resurrected Ceilometer API from the "designated sections" that users are required to run to participate in any trademark program that includes the functionality in question. But I think that we should explore other ways of reducing the chance of anyone confusing this for a viable way of building a cloud, including possibly changing the name (Antediluvian API?) and having this part of the stack live outside of the official OpenStack project.
Legacy API?
-- Thierry Carrez (ttx)
Hi, we have held a presentation in Shanghai on that topic if that's of help for anyone: https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/23932/... We've compared the technology of Telemetry and Monasca and how specific use cases like billing or auto-scaling are implemented. Monasca is a valid replacement option for Gnocchi. On 12/18/19 6:37 AM, Lingxian Kong wrote:
2. Monasca is also good, although it doesn't support auditing i.e. storing samples which is needed by billing purpose but I didn't see it's mentioned by anyone in this thread.
I have to disagree with that. Monasca is used for billing in production.
What's more, it introduces kafaka which is not usually used in all other openstack core services.
Yes, we decided to use Apache Kafka as it's better suited than RabbitMQ to pass large loads of data with high throughput. Building the system around Kafka allows us to provide fault-tolerance and scalability. Best greetings Witek
On Thu, Dec 19, 2019 at 1:24 AM Witek Bedyk <witold.bedyk@suse.com> wrote:
Yes, we decided to use Apache Kafka as it's better suited than RabbitMQ to pass large loads of data with high throughput. Building the system around Kafka allows us to provide fault-tolerance and scalability.
Hi Witek, I think I've mentioned in this thread or other related emails MANY times, or even face-to-face with you in the Shanghai Summit. I never doubt that Monasca is doing great job with the current architecture, I totally understand that people choose it in production. As an open source community, nothing could stop us from integrating it with Ceilometer(and I think it's already supported[1]). [1]: https://github.com/openstack/ceilometer/blob/master/setup.cfg#L209 - Best regards, Lingxian Kong Catalyst Cloud
On 18 Dec 2019, at 11:19 pm, Witek Bedyk <witold.bedyk@suse.com> wrote:
Hi,
we have held a presentation in Shanghai on that topic if that's of help for anyone:
https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/23932/...
We've compared the technology of Telemetry and Monasca and how specific use cases like billing or auto-scaling are implemented. Monasca is a valid replacement option for Gnocchi.
On 12/18/19 6:37 AM, Lingxian Kong wrote:
2. Monasca is also good, although it doesn't support auditing i.e. storing samples which is needed by billing purpose but I didn't see it's mentioned by anyone in this thread.
I have to disagree with that. Monasca is used for billing in production.
What's more, it introduces kafaka which is not usually used in all other openstack core services.
Yes, we decided to use Apache Kafka as it's better suited than RabbitMQ to pass large loads of data with high throughput. Building the system around Kafka allows us to provide fault-tolerance and scalability.
It would make it a whole lot easier to switch to Monasca if it supported RabbitMQ too. RabbitMQ also provides fault tolerance, scalability and can handle high throughput etc. Having to operate and maintain another queuing system is a big hurdle for us. Sam
Lingxian Kong wrote:
[...] 1. Maybe Gnocchi is good, but it's not part of OpenStack, currently there is no one in the Telemetry team shows any interest in maintaining it, I'd be very happy to see if there is someone raises hand and say: I can commit to spend some time on this project, fixing bugs, maintaining document and answering questions either on IRC or via email. If yes, We will see how it goes in this dev cycle.
Is there any specific standing issue with Gnocchi that you are blocked on ? Or is it more of a general concern that you should not depend on an unmaintained project ? If it's the latter (and there is no real burning issue with it), it feels like forking or taking over Gnocchi, and then keep it barely functional enough for OpenStack use case might not be that much of work (compared to other options) and we might find volunteers in this thread to help. To me that would be a better short-term plan, while some lower-maintenance long-term solution is designed (be it combining Monasca and Ceilometer, or starting from scratch and leveraging some new cool tech). -- Thierry Carrez (ttx)
On Thu, Dec 19, 2019 at 2:08 AM Thierry Carrez <thierry@openstack.org> wrote:
Lingxian Kong wrote:
[...] 1. Maybe Gnocchi is good, but it's not part of OpenStack, currently there is no one in the Telemetry team shows any interest in maintaining it, I'd be very happy to see if there is someone raises hand and say: I can commit to spend some time on this project, fixing bugs, maintaining document and answering questions either on IRC or via email. If yes, We will see how it goes in this dev cycle.
Is there any specific standing issue with Gnocchi that you are blocked on ? Or is it more of a general concern that you should not depend on an unmaintained project ?
Many people were asking for the cpu_util support that was in Ceilometer but not in Gnocchi which is important in auto-scaling scenario, but no one knows the history. Gnocchi doc website is broken and no one is available to fix. No one maintains Gnocchi CI. Sometimes people are coming to #openstack-telemetry for questions or potential bug report, but on one is answering, which makes people rather disappointed.
If it's the latter (and there is no real burning issue with it), it feels like forking or taking over Gnocchi, and then keep it barely functional enough for OpenStack use case might not be that much of work (compared to other options) and we might find volunteers in this thread to help.
+1 - Best regards, Lingxian Kong Catalyst Cloud
On Wed, 18 Dec 2019 at 21:33, Lingxian Kong <anlin.kong@gmail.com> wrote:
Gnocchi doc website is broken and no one is available to fix. No one maintains Gnocchi CI.
I have just noticed that the Gnocchi website is published again at a new address: http://gnocchi.osci.io See https://github.com/gnocchixyz/gnocchi/pull/1053 for the change.
On Wed, Dec 18, 2019 at 1:43 PM Lingxian Kong <anlin.kong@gmail.com> wrote:
Hi all,
1. Maybe Gnocchi is good, but it's not part of OpenStack, currently there is no one in the Telemetry team shows any interest in maintaining it, I'd be very happy to see if there is someone raises hand and say: I
can
commit to spend some time on this project, fixing bugs, maintaining document and answering questions either on IRC or via email. If yes, We will see how it goes in this dev cycle.
If Gnocchi can't provide documents and CI, also can't close the issue said `Project is unmaintained`[1], we should ask if anyone here volunteer to resolved that part. Anyone?:) If you really care about Gnocchi+Telemetry, join the team please.
3. The Telemetry team did have discussed to bring the Ceilometer API and MongoDB support back, given neither Gnocchi nor Monasca is able to store the original samples. However, nothing is happening, so don't be panic.
From my perspective, to bring back Ceilometer API and MongoDB as another driver for Telemetry isn't a bad idea at all as long as other driver can keep their tasks forward. No one (at least I didn't see any one) mentioned about if some people in Telemetry team start the effort on Ceilometer API and MongoDB, no others can keep their effort on Gnocchi.
The one thing I'm interested on is how to tune the MongoDB performance with Ceilometer. How can you make Ceilometer API+MongoDB more robust? So if any chances that's happening, will be create to provide related documents too. Also the CI need to be there when we bring back Ceilometer API and MongoDB support. Despite the detail is not yet develop here, I'm agree if that's a short-term plan. [1] https://github.com/gnocchixyz/gnocchi/issues/1049
the current project core members are also the Telemetry service cloud providers, we know how important it is to not break anything, to not bring any more overhead than before. we are so glad to see this
I believe that's really important for you guys too:)
discussion, at least there are still so many people using Ceilometer/Gnocchi and have concerns about the current upstream situation. It would be much better that people involved in this discussion could participate in the design and implementation of the future tasks.
Yes, the only way is to join the team, stand your ground, and involve in the design. In long term, IMO we need to have a ultimate solution for all. A standard way so whatever other tools or service is developing, on the other can use it too. An tool/sdk/interface (and no need to build another service) to support both project. Or if there's better solution for it. And what need to done if we would like that. Will Telemetry and Monasca team interested on this? I would like to propose we move that discussion somewhere else, like in Monasca or Telemetry's team meeting? Will ask if any TC can help to coordinate. -- May The Force of OpenStack Be With You, Rico Lin irc: ricolin
Just another ML earlier people need to also aware of -> http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010923.... On Thu, Dec 19, 2019 at 10:07 AM Rico Lin <rico.lin.guanyu@gmail.com> wrote:
On Wed, Dec 18, 2019 at 1:43 PM Lingxian Kong <anlin.kong@gmail.com> wrote:
Hi all,
1. Maybe Gnocchi is good, but it's not part of OpenStack, currently there is no one in the Telemetry team shows any interest in maintaining it, I'd be very happy to see if there is someone raises hand and say: I
can
commit to spend some time on this project, fixing bugs, maintaining document and answering questions either on IRC or via email. If yes, We will see how it goes in this dev cycle.
If Gnocchi can't provide documents and CI, also can't close the issue said `Project is unmaintained`[1], we should ask if anyone here volunteer to resolved that part. Anyone?:) If you really care about Gnocchi+Telemetry, join the team please.
3. The Telemetry team did have discussed to bring the Ceilometer API and MongoDB support back, given neither Gnocchi nor Monasca is able to store the original samples. However, nothing is happening, so don't be panic.
From my perspective, to bring back Ceilometer API and MongoDB as another driver for Telemetry isn't a bad idea at all as long as other driver can keep their tasks forward. No one (at least I didn't see any one) mentioned about if some people in Telemetry team start the effort on Ceilometer API and MongoDB, no others can keep their effort on Gnocchi.
The one thing I'm interested on is how to tune the MongoDB performance with Ceilometer. How can you make Ceilometer API+MongoDB more robust? So if any chances that's happening, will be create to provide related documents too. Also the CI need to be there when we bring back Ceilometer API and MongoDB support.
Despite the detail is not yet develop here, I'm agree if that's a short-term plan.
[1] https://github.com/gnocchixyz/gnocchi/issues/1049
the current project core members are also the Telemetry service cloud providers, we know how important it is to not break anything, to not bring any more overhead than before. we are so glad to see this
I believe that's really important for you guys too:)
discussion, at least there are still so many people using Ceilometer/Gnocchi and have concerns about the current upstream situation. It would be much better that people involved in this discussion could participate in the design and implementation of the future tasks.
Yes, the only way is to join the team, stand your ground, and involve in the design.
In long term, IMO we need to have a ultimate solution for all. A standard way so whatever other tools or service is developing, on the other can use it too. An tool/sdk/interface (and no need to build another service) to support both project. Or if there's better solution for it. And what need to done if we would like that. Will Telemetry and Monasca team interested on this? I would like to propose we move that discussion somewhere else, like in Monasca or Telemetry's team meeting? Will ask if any TC can help to coordinate.
-- May The Force of OpenStack Be With You, Rico Lin irc: ricolin
-- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin
On 12/19/19 3:07 AM, Rico Lin wrote:
In long term, IMO we need to have a ultimate solution for all. A standard way so whatever other tools or service is developing, on the other can use it too. An tool/sdk/interface (and no need to build another service) to support both project. Or if there's better solution for it. And what need to done if we would like that. Will Telemetry and Monasca team interested on this? I would like to propose we move that discussion somewhere else, like in Monasca or Telemetry's team meeting? Will ask if any TC can help to coordinate.
I'm definitely interested in discussing long-term solution for monitoring as Thierry suggested. Cheers Witek
As an operator I second pretty much everything Samsaid, using ceilometer-api never really worked without hand holding all the time. We migrated over to Gnocchi as that was "the way forward" from the Telemetry team and it has worked great. Gnocchi has a learning curve but after that it has been running flawlessly even at a larger scale, just introduced more workers and everything is set. I think the long term plan from the Telemetry team was to move out any storage abstraction and cultivate ceilometer to a single focus area around collecting metrics. Moving any API, transformations, storage etc to another service. I think it's said to see Gnocchi, the actual solutions to the problem, being unmaintained and out of the OpenStack developer ecosystem. I assume there is a cost to bringing it back in after it was moved out but maybe it's something that is needed? While I don't have a deep understand in Gnocchi I would have no choice but to try to spend more time learning it and fixing any issues that we might see since at this point we can't live without it, as our billing providers supports the Gnocchi API, we using Heat with Gnocchi and Aodh to autoscale etc. As a final note; thanks for bringing back the cpu_util metric, means I can drop the ugly customized code that was required to bring that metric back while it was removed :) Best regards Tobias On 12/18/19 5:39 AM, Sam Morrison wrote:
On 17 Dec 2019, at 10:14 pm, Thierry Carrez <thierry@openstack.org> wrote:
Zane Bitter wrote:
On 15/12/19 10:20 pm, Rong Zhu wrote:
1.Add Ceilometer API back Since Gnocchi is out of OpenStack and is unmaintained, we need to add Ceilometer API back again. This is concerning because even the people who wrote it don't consider it adequate to the job. That inadequacy has been the source of significant reputational damage to OpenStack in the past, and many folks (me included) are anxious to avoid a repeat. Yes this concerns me too, and even if we workaround the issue by adding Ceilo API back, I'd like to have a long-term plan to solve this issue. It seems there are several options on the table (including integrating Monasca and Ceilometer into a single stack, and other big-bang replacements) but it's never a one-for-one comparison as the solutions seem to address slightly disjoint problem spaces.
I'd like to hear from more Ceilometer users. What are they using Ceilometer for, and what long-term plans would be acceptable. There is a trade-off between adopting short-term workarounds that reintroduce performance issues vs. undergoing a complex migration to the "right" way of fixing this. Like for example there is little point in pushing Monasca/Ceilometer stack integration if most users say, like Catalyst Cloud seems to say, that they would rather have a slow performing Ceilometer API back. Nectar Cloud has been a ceilometer user from the early days. Well we tried to be and couldn’t use it as ceilometer api and mongo db just didn’t work at our scale. Gnocchi solved all these issues for us and we use ceilometer/aodh/gnocchi happily in production for several years now. If telemetry project is going down the path of the old days it will mean we will either drop ceilometer all together and look at alternative solutions like monasca or Prometheus etc. I just can’t see how the old architecture of ceilometer is ever going to be usable.
If there is some confidence that gnocchi publisher will be supported in the future we would keep using gnocchi and just maintain it ourselves. It’s an open source project and I was hoping the openstack community could keep it going. We’d be happy to help maintain it at least.
We use ceilometer/gnocchi to collect and store all metrics from openstack services. We have also written some custom pollsters and gnocchi is quite flexible here to allow this. With these metrics we build reports for our users, our operators, our funders (the government)
Please reconsider your direction much like adding cpu_util back in (thank you for this!)
Cheers, Sam
Telemetry is part of the TC "Approved Release" that is eligible for the trademark program; I think at a minimum the TC will want to remove the resurrected Ceilometer API from the "designated sections" that users are required to run to participate in any trademark program that includes the functionality in question. But I think that we should explore other ways of reducing the chance of anyone confusing this for a viable way of building a cloud, including possibly changing the name (Antediluvian API?) and having this part of the stack live outside of the official OpenStack project. Legacy API?
-- Thierry Carrez (ttx)
https://github.com/gnocchixyz/gnocchi/issues/1049#issuecomment-555768072 On 12/18/19 10:15 AM, Tobias Urdin wrote:
As an operator I second pretty much everything Samsaid, using ceilometer-api never really worked without hand holding all the time. We migrated over to Gnocchi as that was "the way forward" from the Telemetry team and it has worked great.
Gnocchi has a learning curve but after that it has been running flawlessly even at a larger scale, just introduced more workers and everything is set.
I think the long term plan from the Telemetry team was to move out any storage abstraction and cultivate ceilometer to a single focus area around collecting metrics. Moving any API, transformations, storage etc to another service.
I think it's said to see Gnocchi, the actual solutions to the problem, being unmaintained and out of the OpenStack developer ecosystem. I assume there is a cost to bringing it back in after it was moved out but maybe it's something that is needed?
While I don't have a deep understand in Gnocchi I would have no choice but to try to spend more time learning it and fixing any issues that we might see since at this point we can't live without it, as our billing providers supports the Gnocchi API, we using Heat with Gnocchi and Aodh to autoscale etc.
As a final note; thanks for bringing back the cpu_util metric, means I can drop the ugly customized code that was required to bring that metric back while it was removed :)
Best regards Tobias
On 12/18/19 5:39 AM, Sam Morrison wrote:
On 17 Dec 2019, at 10:14 pm, Thierry Carrez <thierry@openstack.org> wrote:
Zane Bitter wrote:
On 15/12/19 10:20 pm, Rong Zhu wrote:
1.Add Ceilometer API back Since Gnocchi is out of OpenStack and is unmaintained, we need to add Ceilometer API back again. This is concerning because even the people who wrote it don't consider it adequate to the job. That inadequacy has been the source of significant reputational damage to OpenStack in the past, and many folks (me included) are anxious to avoid a repeat. Yes this concerns me too, and even if we workaround the issue by adding Ceilo API back, I'd like to have a long-term plan to solve this issue. It seems there are several options on the table (including integrating Monasca and Ceilometer into a single stack, and other big-bang replacements) but it's never a one-for-one comparison as the solutions seem to address slightly disjoint problem spaces.
I'd like to hear from more Ceilometer users. What are they using Ceilometer for, and what long-term plans would be acceptable. There is a trade-off between adopting short-term workarounds that reintroduce performance issues vs. undergoing a complex migration to the "right" way of fixing this. Like for example there is little point in pushing Monasca/Ceilometer stack integration if most users say, like Catalyst Cloud seems to say, that they would rather have a slow performing Ceilometer API back. Nectar Cloud has been a ceilometer user from the early days. Well we tried to be and couldn’t use it as ceilometer api and mongo db just didn’t work at our scale. Gnocchi solved all these issues for us and we use ceilometer/aodh/gnocchi happily in production for several years now. If telemetry project is going down the path of the old days it will mean we will either drop ceilometer all together and look at alternative solutions like monasca or Prometheus etc. I just can’t see how the old architecture of ceilometer is ever going to be usable.
If there is some confidence that gnocchi publisher will be supported in the future we would keep using gnocchi and just maintain it ourselves. It’s an open source project and I was hoping the openstack community could keep it going. We’d be happy to help maintain it at least.
We use ceilometer/gnocchi to collect and store all metrics from openstack services. We have also written some custom pollsters and gnocchi is quite flexible here to allow this. With these metrics we build reports for our users, our operators, our funders (the government)
Please reconsider your direction much like adding cpu_util back in (thank you for this!)
Cheers, Sam
Telemetry is part of the TC "Approved Release" that is eligible for the trademark program; I think at a minimum the TC will want to remove the resurrected Ceilometer API from the "designated sections" that users are required to run to participate in any trademark program that includes the functionality in question. But I think that we should explore other ways of reducing the chance of anyone confusing this for a viable way of building a cloud, including possibly changing the name (Antediluvian API?) and having this part of the stack live outside of the official OpenStack project. Legacy API?
-- Thierry Carrez (ttx)
I just want to know any other guys from the thread want to as volunteers to take over gnocchi? About Monasca, we discuss a lot in Shanghai, if users already use monasca, as Lingxian mentioned ceilometer has already support publish to monasca. but I think most of the user didn't use monasca, as a community you can just say use monasca, but for company want to use in production, add a component and the depends extra tools would be very very difficult, this will need many many resources to do the things. Tobias Urdin <tobias.urdin@binero.se>于2019年12月18日 周三18:00写道：
https://github.com/gnocchixyz/gnocchi/issues/1049#issuecomment-555768072
As an operator I second pretty much everything Samsaid, using ceilometer-api never really worked without hand holding all the time. We migrated over to Gnocchi as that was "the way forward" from the Telemetry team and it has worked great.
Gnocchi has a learning curve but after that it has been running flawlessly even at a larger scale, just introduced more workers and everything is set.
I think the long term plan from the Telemetry team was to move out any storage abstraction and cultivate ceilometer to a single focus area around collecting metrics. Moving any API, transformations, storage etc to another service.
I think it's said to see Gnocchi, the actual solutions to the problem, being unmaintained and out of the OpenStack developer ecosystem. I assume there is a cost to bringing it back in after it was moved out but maybe it's something that is needed?
While I don't have a deep understand in Gnocchi I would have no choice but to try to spend more time learning it and fixing any issues that we might see since at this point we can't live without it, as our billing providers supports the Gnocchi API, we using Heat with Gnocchi and Aodh to autoscale etc.
As a final note; thanks for bringing back the cpu_util metric, means I can drop the ugly customized code that was required to bring that metric back while it was removed :)
Best regards Tobias
On 12/18/19 5:39 AM, Sam Morrison wrote:
On 17 Dec 2019, at 10:14 pm, Thierry Carrez <thierry@openstack.org> wrote:
Zane Bitter wrote:
On 15/12/19 10:20 pm, Rong Zhu wrote:
1.Add Ceilometer API back Since Gnocchi is out of OpenStack and is unmaintained, we need to add Ceilometer API back again. This is concerning because even the people who wrote it don't consider it adequate to the job. That inadequacy has been the source of significant reputational damage to OpenStack in the past, and many folks (me included) are anxious to avoid a repeat. Yes this concerns me too, and even if we workaround the issue by adding Ceilo API back, I'd like to have a long-term plan to solve this issue. It seems there are several options on the table (including integrating Monasca and Ceilometer into a single stack, and other big-bang replacements) but it's never a one-for-one comparison as the solutions seem to address slightly disjoint problem spaces.
I'd like to hear from more Ceilometer users. What are they using Ceilometer for, and what long-term plans would be acceptable. There is a
Nectar Cloud has been a ceilometer user from the early days. Well we
If telemetry project is going down the path of the old days it will mean we will either drop ceilometer all together and look at alternative solutions like monasca or Prometheus etc. I just can’t see how the old architecture of ceilometer is ever going to be usable.
If there is some confidence that gnocchi publisher will be supported in
We use ceilometer/gnocchi to collect and store all metrics from
openstack services. We have also written some custom pollsters and gnocchi is quite flexible here to allow this. With these metrics we build reports for our users, our operators, our funders (the government)
Please reconsider your direction much like adding cpu_util back in
(thank you for this!)
Cheers, Sam
Telemetry is part of the TC "Approved Release" that is eligible for
On 12/18/19 10:15 AM, Tobias Urdin wrote: trade-off between adopting short-term workarounds that reintroduce performance issues vs. undergoing a complex migration to the "right" way of fixing this. Like for example there is little point in pushing Monasca/Ceilometer stack integration if most users say, like Catalyst Cloud seems to say, that they would rather have a slow performing Ceilometer API back. tried to be and couldn’t use it as ceilometer api and mongo db just didn’t work at our scale. Gnocchi solved all these issues for us and we use ceilometer/aodh/gnocchi happily in production for several years now. the future we would keep using gnocchi and just maintain it ourselves. It’s an open source project and I was hoping the openstack community could keep it going. We’d be happy to help maintain it at least. the trademark program; I think at a minimum the TC will want to remove the resurrected Ceilometer API from the "designated sections" that users are required to run to participate in any trademark program that includes the functionality in question. But I think that we should explore other ways of reducing the chance of anyone confusing this for a viable way of building a cloud, including possibly changing the name (Antediluvian API?) and having this part of the stack live outside of the official OpenStack project.
Legacy API?
-- Thierry Carrez (ttx)
-- Thanks, Rong Zhu
Another worry is Monasca's main contributors are from SUSE. Rong Zhu <aaronzhu1121@gmail.com>于2019年12月19日 周四09:41写道：
I just want to know any other guys from the thread want to as volunteers to take over gnocchi?
About Monasca, we discuss a lot in Shanghai, if users already use monasca, as Lingxian mentioned ceilometer has already support publish to monasca. but I think most of the user didn't use monasca, as a community you can just say use monasca, but for company want to use in production, add a component and the depends extra tools would be very very difficult, this will need many many resources to do the things.
Tobias Urdin <tobias.urdin@binero.se>于2019年12月18日 周三18:00写道：
https://github.com/gnocchixyz/gnocchi/issues/1049#issuecomment-555768072
As an operator I second pretty much everything Samsaid, using ceilometer-api never really worked without hand holding all the time. We migrated over to Gnocchi as that was "the way forward" from the Telemetry team and it has worked great.
Gnocchi has a learning curve but after that it has been running flawlessly even at a larger scale, just introduced more workers and everything is set.
I think the long term plan from the Telemetry team was to move out any storage abstraction and cultivate ceilometer to a single focus area around collecting metrics. Moving any API, transformations, storage etc to another service.
I think it's said to see Gnocchi, the actual solutions to the problem, being unmaintained and out of the OpenStack developer ecosystem. I assume there is a cost to bringing it back in after it was moved out but maybe it's something that is needed?
While I don't have a deep understand in Gnocchi I would have no choice but to try to spend more time learning it and fixing any issues that we might see since at this point we can't live without it, as our billing providers supports the Gnocchi API, we using Heat with Gnocchi and Aodh to autoscale etc.
As a final note; thanks for bringing back the cpu_util metric, means I can drop the ugly customized code that was required to bring that metric back while it was removed :)
Best regards Tobias
On 12/18/19 5:39 AM, Sam Morrison wrote:
On 17 Dec 2019, at 10:14 pm, Thierry Carrez <thierry@openstack.org> wrote:
Zane Bitter wrote:
On 15/12/19 10:20 pm, Rong Zhu wrote: > 1.Add Ceilometer API back > Since Gnocchi is out of OpenStack and is unmaintained, we need to add Ceilometer API back again. This is concerning because even the people who wrote it don't consider it adequate to the job. That inadequacy has been the source of significant reputational damage to OpenStack in the past, and many folks (me included) are anxious to avoid a repeat. Yes this concerns me too, and even if we workaround the issue by adding Ceilo API back, I'd like to have a long-term plan to solve this issue. It seems there are several options on the table (including integrating Monasca and Ceilometer into a single stack, and other big-bang replacements) but it's never a one-for-one comparison as the solutions seem to address slightly disjoint problem spaces.
I'd like to hear from more Ceilometer users. What are they using Ceilometer for, and what long-term plans would be acceptable. There is a
Nectar Cloud has been a ceilometer user from the early days. Well we
If telemetry project is going down the path of the old days it will mean we will either drop ceilometer all together and look at alternative solutions like monasca or Prometheus etc. I just can’t see how the old architecture of ceilometer is ever going to be usable.
If there is some confidence that gnocchi publisher will be supported in the future we would keep using gnocchi and just maintain it ourselves. It’s an open source project and I was hoping the openstack community could keep it going. We’d be happy to help maintain it at least.
We use ceilometer/gnocchi to collect and store all metrics from openstack services. We have also written some custom pollsters and gnocchi is quite flexible here to allow this. With these metrics we build reports for our users, our operators, our funders (the government)
Please reconsider your direction much like adding cpu_util back in (thank you for this!)
Cheers, Sam
Telemetry is part of the TC "Approved Release" that is eligible for
On 12/18/19 10:15 AM, Tobias Urdin wrote: trade-off between adopting short-term workarounds that reintroduce performance issues vs. undergoing a complex migration to the "right" way of fixing this. Like for example there is little point in pushing Monasca/Ceilometer stack integration if most users say, like Catalyst Cloud seems to say, that they would rather have a slow performing Ceilometer API back. tried to be and couldn’t use it as ceilometer api and mongo db just didn’t work at our scale. Gnocchi solved all these issues for us and we use ceilometer/aodh/gnocchi happily in production for several years now. the trademark program; I think at a minimum the TC will want to remove the resurrected Ceilometer API from the "designated sections" that users are required to run to participate in any trademark program that includes the functionality in question. But I think that we should explore other ways of reducing the chance of anyone confusing this for a viable way of building a cloud, including possibly changing the name (Antediluvian API?) and having this part of the stack live outside of the official OpenStack project.
Legacy API?
-- Thierry Carrez (ttx)
-- Thanks, Rong Zhu
-- Thanks, Rong Zhu
On 12/19/19 4:50 AM, Rong Zhu wrote:
Another worry is Monasca's main contributors are from SUSE.
What I am not confident with, is that Monasca needs Java stuff. In here: https://github.com/openstack/monasca-common/blob/master/bindep.txt we can see openjdk-8-jdk. That's already obsolete. For example, Debian Buster was released last summer with openjdk 11, and version 8 isn't available anymore. With such situation, I don't think it's reasonable to attempt packaging Monasca for Debian and Ubuntu, and I'm not even scratching the Java module dependency issue: these would need to be packaged too, and I have no idea how much work that would be (can someone tell me?). If some upstream contributors of Monasca want to bring more light to this topic, please feel free. I obviously don't know enough about it. Cheers, Thomas Goirand (zigo)
On 19/12/2019 10:31, Thomas Goirand wrote:
On 12/19/19 4:50 AM, Rong Zhu wrote:
Another worry is Monasca's main contributors are from SUSE. What I am not confident with, is that Monasca needs Java stuff. In here: https://github.com/openstack/monasca-common/blob/master/bindep.txt
we can see openjdk-8-jdk. That's already obsolete. For example, Debian Buster was released last summer with openjdk 11, and version 8 isn't available anymore.
With such situation, I don't think it's reasonable to attempt packaging Monasca for Debian and Ubuntu, and I'm not even scratching the Java module dependency issue: these would need to be packaged too, and I have no idea how much work that would be (can someone tell me?).
If some upstream contributors of Monasca want to bring more light to this topic, please feel free. I obviously don't know enough about it. A non-Java Monasca deployment is possible if you don't require alerting. There is a plan to replace the alerting service, but I'm unsure if it will be complete this cycle.
Cheers,
Thomas Goirand (zigo)
I can volounteer to spend time on Ceilomter and Gnocchi while I have some mimimal knowledge on Ceilomter and pretty much none on the Gnocchi codebase I would like to see the project continued. Another thing would be if Gnocchi should be moved back or if I should somehow get in contact with the former Gnocchi maintainers and see if we can get access to GitHub? Best regards On 12/19/19 2:46 AM, Rong Zhu wrote:
I just want to know any other guys from the thread want to as volunteers to take over gnocchi?
About Monasca, we discuss a lot in Shanghai, if users already use monasca, as Lingxian mentioned ceilometer has already support publish to monasca. but I think most of the user didn't use monasca, as a community you can just say use monasca, but for company want to use in production, add a component and the depends extra tools would be very very difficult, this will need many many resources to do the things.
Tobias Urdin <tobias.urdin@binero.se <mailto:tobias.urdin@binero.se>>于2019年12月18日 周三18:00写道：
https://github.com/gnocchixyz/gnocchi/issues/1049#issuecomment-555768072
On 12/18/19 10:15 AM, Tobias Urdin wrote: > As an operator I second pretty much everything Samsaid, using > ceilometer-api never really worked without hand holding all the time. > We migrated over to Gnocchi as that was "the way forward" from the > Telemetry team and it has worked great. > > Gnocchi has a learning curve but after that it has been running > flawlessly even at a larger scale, just introduced more workers and > everything is set. > > I think the long term plan from the Telemetry team was to move out any > storage abstraction and cultivate ceilometer to a single focus area around > collecting metrics. Moving any API, transformations, storage etc to > another service. > > I think it's said to see Gnocchi, the actual solutions to the problem, > being unmaintained and out of the OpenStack developer ecosystem. I > assume there > is a cost to bringing it back in after it was moved out but maybe it's > something that is needed? > > While I don't have a deep understand in Gnocchi I would have no choice > but to try to spend more time learning it and fixing any issues that we > might > see since at this point we can't live without it, as our billing > providers supports the Gnocchi API, we using Heat with Gnocchi and Aodh > to autoscale etc. > > As a final note; thanks for bringing back the cpu_util metric, means I > can drop the ugly customized code that was required to bring that metric > back while > it was removed :) > > Best regards > Tobias > > On 12/18/19 5:39 AM, Sam Morrison wrote: >>> On 17 Dec 2019, at 10:14 pm, Thierry Carrez <thierry@openstack.org <mailto:thierry@openstack.org>> wrote: >>> >>> Zane Bitter wrote: >>>> On 15/12/19 10:20 pm, Rong Zhu wrote: >>>>> 1.Add Ceilometer API back >>>>> Since Gnocchi is out of OpenStack and is unmaintained, we need to add Ceilometer API back again. >>>> This is concerning because even the people who wrote it don't consider it adequate to the job. That inadequacy has been the source of significant reputational damage to OpenStack in the past, and many folks (me included) are anxious to avoid a repeat. >>> Yes this concerns me too, and even if we workaround the issue by adding Ceilo API back, I'd like to have a long-term plan to solve this issue. It seems there are several options on the table (including integrating Monasca and Ceilometer into a single stack, and other big-bang replacements) but it's never a one-for-one comparison as the solutions seem to address slightly disjoint problem spaces. >>> >>> I'd like to hear from more Ceilometer users. What are they using Ceilometer for, and what long-term plans would be acceptable. There is a trade-off between adopting short-term workarounds that reintroduce performance issues vs. undergoing a complex migration to the "right" way of fixing this. Like for example there is little point in pushing Monasca/Ceilometer stack integration if most users say, like Catalyst Cloud seems to say, that they would rather have a slow performing Ceilometer API back. >> Nectar Cloud has been a ceilometer user from the early days. Well we tried to be and couldn’t use it as ceilometer api and mongo db just didn’t work at our scale. Gnocchi solved all these issues for us and we use ceilometer/aodh/gnocchi happily in production for several years now. >> If telemetry project is going down the path of the old days it will mean we will either drop ceilometer all together and look at alternative solutions like monasca or Prometheus etc. I just can’t see how the old architecture of ceilometer is ever going to be usable. >> >> If there is some confidence that gnocchi publisher will be supported in the future we would keep using gnocchi and just maintain it ourselves. It’s an open source project and I was hoping the openstack community could keep it going. We’d be happy to help maintain it at least. >> >> We use ceilometer/gnocchi to collect and store all metrics from openstack services. We have also written some custom pollsters and gnocchi is quite flexible here to allow this. With these metrics we build reports for our users, our operators, our funders (the government) >> >> >> Please reconsider your direction much like adding cpu_util back in (thank you for this!) >> >> Cheers, >> Sam >> >> >> >>>> Telemetry is part of the TC "Approved Release" that is eligible for the trademark program; I think at a minimum the TC will want to remove the resurrected Ceilometer API from the "designated sections" that users are required to run to participate in any trademark program that includes the functionality in question. But I think that we should explore other ways of reducing the chance of anyone confusing this for a viable way of building a cloud, including possibly changing the name (Antediluvian API?) and having this part of the stack live outside of the official OpenStack project. >>> Legacy API? >>> >>> -- >>> Thierry Carrez (ttx) >>> >> > >
-- Thanks, Rong Zhu
On 12/19/19 11:41 AM, Tobias Urdin wrote:
I can volounteer to spend time on Ceilomter and Gnocchi while I have some mimimal knowledge on Ceilomter and pretty much none on the Gnocchi codebase I would like to see the project continued.
Another thing would be if Gnocchi should be moved back or if I should somehow get in contact with the former Gnocchi maintainers and see if we can get access to GitHub?
Best regards
Hi Tobias, I believe Julien Danjou will be fine with both options. Just ask him, I'm convince he will reply quickly, and will be happy if someone takes over his work (and the other people involved in the former team). If my non-volunteering voice has some weight, I'd very much prefer if the project could go back to being OpenStack maintained. It would be reassuring in many ways. Cheers, Thomas Goirand (zigo)
Tobias Urdin wrote:
I can volounteer to spend time on Ceilomter and Gnocchi while I have some mimimal knowledge on Ceilomter and pretty much none on the Gnocchi codebase I would like to see the project continued.
Another thing would be if Gnocchi should be moved back or if I should somehow get in contact with the former Gnocchi maintainers and see if we can get access to GitHub?
If the goal is to maintain Gnocchi as-is for the narrow OpenStack use case, my preference would be to fork / move it back to opendev, under a gnocchi namespace. That would ensure a clean cut from the unmaintained "gnocchi for all the things" project on GitHub, and reset expectations. If the goal is to take over Gnocchi and support all other use cases, then maybe taking it over on GitHub might be easier to ensure continuity. -- Thierry Carrez (ttx)
I'd prefer we fork Gnocchi to opendev/gerrit so the developers could have the same experiences with other openstack projects. Before people fixing any bugs or developing any features, the first task is to set up the CI and publish docs in openstack website. I can offer some help as well. - Best regards, Lingxian Kong Catalyst Cloud On Fri, Dec 20, 2019 at 3:06 AM Thierry Carrez <thierry@openstack.org> wrote:
Tobias Urdin wrote:
I can volounteer to spend time on Ceilomter and Gnocchi while I have some mimimal knowledge on Ceilomter and pretty much none on the Gnocchi codebase I would like to see the project continued.
Another thing would be if Gnocchi should be moved back or if I should somehow get in contact with the former Gnocchi maintainers and see if we can get access to GitHub?
If the goal is to maintain Gnocchi as-is for the narrow OpenStack use case, my preference would be to fork / move it back to opendev, under a gnocchi namespace. That would ensure a clean cut from the unmaintained "gnocchi for all the things" project on GitHub, and reset expectations.
If the goal is to take over Gnocchi and support all other use cases, then maybe taking it over on GitHub might be easier to ensure continuity.
-- Thierry Carrez (ttx)
I am happy to help out with Gnocchi too. I have experience with the code base and wrote an influxdb backend for gnocchi but it was around the time it got split off from openstack and it never made it in. [1] (we use an updated patch in production) I can’t think of much needed in the way of extra features for our use case but I would be able to help out on maintenance and also CI issues. Cheers. Sam [1] https://review.opendev.org/#/c/390260/
On 20 Dec 2019, at 11:27 am, Lingxian Kong <anlin.kong@gmail.com> wrote:
I'd prefer we fork Gnocchi to opendev/gerrit so the developers could have the same experiences with other openstack projects. Before people fixing any bugs or developing any features, the first task is to set up the CI and publish docs in openstack website.
I can offer some help as well.
- Best regards, Lingxian Kong Catalyst Cloud
On Fri, Dec 20, 2019 at 3:06 AM Thierry Carrez <thierry@openstack.org <mailto:thierry@openstack.org>> wrote: Tobias Urdin wrote:
I can volounteer to spend time on Ceilomter and Gnocchi while I have some mimimal knowledge on Ceilomter and pretty much none on the Gnocchi codebase I would like to see the project continued.
Another thing would be if Gnocchi should be moved back or if I should somehow get in contact with the former Gnocchi maintainers and see if we can get access to GitHub?
If the goal is to maintain Gnocchi as-is for the narrow OpenStack use case, my preference would be to fork / move it back to opendev, under a gnocchi namespace. That would ensure a clean cut from the unmaintained "gnocchi for all the things" project on GitHub, and reset expectations.
If the goal is to take over Gnocchi and support all other use cases, then maybe taking it over on GitHub might be easier to ensure continuity.
-- Thierry Carrez (ttx)
+1 for forking. But that would probably mandate a slight rename to avoid confusion and announce the change in priorities (ceilometer backend vs general-purpose [however unlikely in practice]). Happy to help from Kolla(-Ansible) side to have it deployed. -yoctozepto pt., 20 gru 2019 o 04:35 Sam Morrison <sorrison@gmail.com> napisał(a):
I am happy to help out with Gnocchi too. I have experience with the code base and wrote an influxdb backend for gnocchi but it was around the time it got split off from openstack and it never made it in. [1] (we use an updated patch in production) I can’t think of much needed in the way of extra features for our use case but I would be able to help out on maintenance and also CI issues.
Cheers. Sam
[1] https://review.opendev.org/#/c/390260/
On 20 Dec 2019, at 11:27 am, Lingxian Kong <anlin.kong@gmail.com> wrote:
I'd prefer we fork Gnocchi to opendev/gerrit so the developers could have the same experiences with other openstack projects. Before people fixing any bugs or developing any features, the first task is to set up the CI and publish docs in openstack website.
I can offer some help as well.
- Best regards, Lingxian Kong Catalyst Cloud
On Fri, Dec 20, 2019 at 3:06 AM Thierry Carrez <thierry@openstack.org> wrote:
Tobias Urdin wrote:
I can volounteer to spend time on Ceilomter and Gnocchi while I have some mimimal knowledge on Ceilomter and pretty much none on the Gnocchi codebase I would like to see the project continued.
Another thing would be if Gnocchi should be moved back or if I should somehow get in contact with the former Gnocchi maintainers and see if we can get access to GitHub?
If the goal is to maintain Gnocchi as-is for the narrow OpenStack use case, my preference would be to fork / move it back to opendev, under a gnocchi namespace. That would ensure a clean cut from the unmaintained "gnocchi for all the things" project on GitHub, and reset expectations.
If the goal is to take over Gnocchi and support all other use cases, then maybe taking it over on GitHub might be easier to ensure continuity.
-- Thierry Carrez (ttx)
Radosław Piliszek wrote:
+1 for forking. But that would probably mandate a slight rename to avoid confusion and announce the change in priorities (ceilometer backend vs general-purpose [however unlikely in practice]).
+1 to renaming if we change the scope of the original project. Something like "ceilodb" would make it clear it's just a data backend for Ceilometer... but I'll let the volunteers taking it over choose :) Happy to help with the infrastructure side of things. -- Thierry
On Fri, 20 Dec 2019, 10:44 Thierry Carrez, <thierry@openstack.org> wrote:
Radosław Piliszek wrote:
+1 for forking. But that would probably mandate a slight rename to avoid confusion and announce the change in priorities (ceilometer backend vs general-purpose [however unlikely in practice]).
+1 to renaming if we change the scope of the original project. Something like "ceilodb" would make it clear it's just a data backend for Ceilometer... but I'll let the volunteers taking it over choose :)
Sounds like a bad idea IMO. I'm sure the codebase is littered with the name gnocchi, and everyone knows it as such. Projects can change scope and direction over time, that's ok if it's advertised.
Happy to help with the infrastructure side of things.
-- Thierry
pt., 20 gru 2019 o 15:34 Mark Goddard <mark@stackhpc.com> napisał(a):
On Fri, 20 Dec 2019, 10:44 Thierry Carrez, <thierry@openstack.org> wrote:
Radosław Piliszek wrote:
+1 for forking. But that would probably mandate a slight rename to avoid confusion and announce the change in priorities (ceilometer backend vs general-purpose [however unlikely in practice]).
+1 to renaming if we change the scope of the original project. Something like "ceilodb" would make it clear it's just a data backend for Ceilometer... but I'll let the volunteers taking it over choose :)
Sounds like a bad idea IMO. I'm sure the codebase is littered with the name gnocchi, and everyone knows it as such. Projects can change scope and direction over time, that's ok if it's advertised.
If advertised, approved and if you are really taking full ownership... Moving it from github to opendev as is would definitely cause some identity trouble. That said, it might be the case we are talking about ghosts - if gnocchi is used like 99.9% as ceilometer backend then it's probably fine whatever we do to make it thrive. Can we somehow get people from gnocchi to discuss the reality? -yoctozepto
On Fri, Dec 20, 2019 at 11:50 PM Thierry Carrez <thierry@openstack.org> wrote:
Happy to help with the infrastructure side of things.
Hi ttx, could you please help to create a project in opendev using the existing Gnocchi repo, or guide me how to do that? - Best regards, Lingxian Kong Catalyst Cloud
Lingxian Kong wrote:
On Fri, Dec 20, 2019 at 11:50 PM Thierry Carrez <thierry@openstack.org <mailto:thierry@openstack.org>> wrote:
Happy to help with the infrastructure side of things.
Hi ttx, could you please help to create a project in opendev using the existing Gnocchi repo, or guide me how to do that?
Hi Lingxian, I'll be on leave until January 6 and mostly offline, so unfortunately I can't really push that migration until I'm back. If you want to try by yourself, the steps to follow are documented at: https://docs.openstack.org/infra/manual/creators.html One early decision to make is whether the project is adopted by an openstack project team (in which case it can be back in the "openstack/" namespace) or if we'd maintain it as a separate project. You can also ask for help in #openstack-infra. -- Thierry Carrez (ttx)
On 12/17/19 4:01 AM, Zane Bitter wrote:
On 15/12/19 10:20 pm, Rong Zhu wrote:
1.Add Ceilometer API back Since Gnocchi is out of OpenStack and is unmaintained, we need to add Ceilometer API back again.
This is concerning because even the people who wrote it don't consider it adequate to the job. That inadequacy has been the source of significant reputational damage to OpenStack in the past, and many folks (me included) are anxious to avoid a repeat.
Telemetry is part of the TC "Approved Release" that is eligible for the trademark program; I think at a minimum the TC will want to remove the resurrected Ceilometer API from the "designated sections" that users are required to run to participate in any trademark program that includes the functionality in question. But I think that we should explore other ways of reducing the chance of anyone confusing this for a viable way of building a cloud, including possibly changing the name (Antediluvian API?) and having this part of the stack live outside of the official OpenStack project.
I'm not clear on which parts of the API you plan to resurrect, but for example - wearing my Heat hat - after a long process of migrating Ceilometer alarm resources in Heat to Aodh ones (mostly involving breaking changes forced on us by the absence of a migration path in Telemetry), I have zero interest in turning around and going back in the other direction. I would infinitely prefer that we find a path to e.g. migrate to Monasca as the collector so that the community can speak with one voice about how to do metrics and alarming in OpenStack.
2.Mongodb database backend support As this thread [0] discuss, there are still some users still use mongodb as the database backend, we decide to add this support again. License issue should consider and fix by user.
So long as this is not the only backend available, I agree the licensing of MongoDB itself is not a concern for OpenStack (we have plenty of drivers that depend on even proprietary software in various places).
The issue that Matthias alluded to in the thread is that Linux distributions are dropping MongoDB due to its non-free license, so it is not nearly as widely and easily available as it was in the past.
The OVH and Catalyst Cloud had fix the mongodb performance issue with some mongodb changes.
It's really hard to reconcile this with the information here (and especially in the linked slide):
https://github.com/gnocchixyz/gnocchi/issues/1049#issuecomment-555768072
Gnoochi will still support as the backed. Other database (like influxdb, ES....), we would happy everyone to submit patches to support as the database backed in ceilometer.
This is good to hear :)
cheers, Zane.
Hi, I very much share Zane's concerns. As a distribution package maintainer, I will *not* re-add a ceilometer-api package. What I don't understand is why you guys aren't taking over Gnocchi, or attempt to use a better time series for Telemetry. I also feel like you're trying to scratch your own itch with MongoDB and Ceilometer API, rather than addressing the issues of the project for the wider community, dismissing both what has been said the the previous thread and what the previous maintainers are telling you (ie: that Ceilometer-api + MongoDB is a very bad idea). Why not instead creating a migration path from MongoDB to something more viable/reliable? Cheers, Thomas Goirand (zigo)
participants (17)
-
Albert Braden
-
Doug Hellmann
-
Doug Szumski
-
Lingxian Kong
-
Mark Goddard
-
Mark Voelker
-
Pierre Riteau
-
Radosław Piliszek
-
Rico Lin
-
Rong Zhu
-
Sam Morrison
-
Thierry Carrez
-
Thomas Goirand
-
Thomas Goirand
-
Tobias Urdin
-
Witek Bedyk
-
Zane Bitter