Open Stack

Another worry is Monasca's main contributors are from SUSE.

Rong Zhu <aaronzhu1121 at 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 at 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 at 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
>
-- 
Thanks,
Rong Zhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191219/462fa4bd/attachment-0001.html>