Open Stack

Hi Tim,

It's exactly a great time for your idea as we are trying to develop the new
roadmap/vision for Telemetry. I put your comment to the brainstorming
etherpad [1]

[1] https://etherpad.openstack.org/p/telemetry-train-roadmap

Bests,

On Thu, May 9, 2019 at 4:24 PM Tim Bell <Tim.Bell at cern.ch> wrote:

> Is it time to rethink the approach to telemetry a bit?
>
>
>
> Having each project provide its telemetry data (such as Swift with statsd
> -
> https://docs.openstack.org/swift/latest/admin/objectstorage-monitoring.html
>
> or using a framework like Prometheus)?
>
>
>
> In the end, the projects are the ones who have the best knowledge of how
> to get the metrics.
>
>
>
> Tim
>
>
>
> *From: *Rafael Weingärtner <rafaelweingartner at gmail.com>
> *Date: *Thursday, 9 May 2019 at 02:51
> *To: *Joseph Davis <joseph.davis at suse.com>
> *Cc: *openstack-discuss <openstack-discuss at lists.openstack.org>, Trinh
> Nguyen <dangtrinhnt at gmail.com>
> *Subject: *Re: [telemetry] Team meeting agenda for tomorrow
>
>
>
> Unfortunately, I have a conflict at that time and will not be able to
> attend.
>
> I do have a little bit of context on the Events deprecation to share.
>
> First, you will note the commit message from the commit [0] when Events
> were deprecated:
>
> "
>
> Deprecate event subsystem
>
> This subsystem has never been finished and is not maintained.
>
> Deprecate it for future removal.
>
> "
>
> I got the impression from jd at the time that there were a number of
> features in Telemetry,
>
> including Panko, that were not really "finished" and that the engineers
> who had worked on them
>
> had moved on to other things, so the features had become unsupported.  In
> late 2018 there was
>
> an effort to clean up things that were not well maintained or didn't fit
> the direction of Telemetry.
>
> See also:
> https://julien.danjou.info/lessons-from-openstack-telemetry-deflation/
>
>
>
> Thanks for the reply Joseph,
>
> I have seen the commit message, and I also read the blog you referenced
> (and other pages related to the same topic) which made us a bit worried. I
> will try to explain our perspective and impressions when we read those blog
> pages. It is also worth noting that we have just started engaging with the
> OpenStack community (so, pardon my ignorance with some parts of OpenStack,
> and how this OpenSource community works). We are already making some
> contributions to Kolla-ansible, and we want to start to contribute back to
> Telemetry as well.
>
> Before getting to the topic of Telemetry, and to be more precise,
> Ceilometer, let me state that I have taken part in other OpenSource
> projects and communities before, but these communities are managed by a
> different organization.
>
> So, Ceilometer; when we were designing and building our OpenStack Cloud,
> where billing is a crucial part of it. Ceilometer was chosen because it
> fits our requirements, working "out of the box" to provide valuable data
> for billing in a high availability fashion. It for sure lacks some
> features, but that is ok when one works with OpenSource. The pollers and
> event managers we are missing, we would like to create and contribute back
> to the community.
>
> Having said that, what puzzled me, and worried us, is the fact that
> features that work are being removed from a project just because some
> contributors/committers left the community. There wasn't (at least I did
> not see) a good technical reason to remove this feature (e.g. it does not
> deliver what is promised, or an alternative solution has been created
> somewhere and effort is being concentrated there, nobody uses it, and so
> on). If the features were broken, and there were no people to fix it, I
> would understand, but that is not the case. The feature works, and it
> delivers what is promised. Moreover, reading the blog you referenced does
> not provide a good feeling about how the community has managed the event
> (the project losing part of its contributors) in question. OpenSource has
> cycles, and it is understandable that sometimes we do not have many people
> working on something. OpenSource projects have cycles, and that is normal.
> As you can see, now there would be us starting/trying to engage with the
> Telemetry project/community. What is hard for us to understand is that the
> contributors while leaving are also "killing" the project by removing part
> of its features (that are very interesting and valuable for us).
>
> Why is that important for us?
> When we work with OpenSource we now that we might need to put effort to
> customize/adapt things to our business workflow, and we expect that the
> community will be there to receive and discuss these changes. Therefore, we
> have predictability that the software/system we base our business will be
> there, and we can contribute back to improve it. An open source community
> could and should live even if the project has no community for a while,
> then if people regroup and start to work on it again, the community is able
> to flourish.
>
>
>
> Events is one feature that often gets requested, but the use cases and
> demand for it are not expressed
>
> strongly or well understood by most people.  If the Telemetry project has
> demand to de-deprecate
>
> Event handling (including Panko), I'd suggest a review of the requirements
> for event handling and
>
> possibly choosing a champion for maintaining the Panko service.
>
>
>
> Also note: over in Monasca we have a spec [1] for handling Events
> ingestion which I hope we will be
>
> completing in Train.  Contributions and comments welcome. :)
>
>
>
> joseph
>
> [0]
> https://github.com/openstack/ceilometer/commit/8a0245a5b3e1357d35ad6653be37ca01176577e4
>
> [1]
> https://github.com/openstack/monasca-specs/blob/master/specs/stein/approved/monasca-events-listener.rst
>
>
>
> It is awesome that you might have a similar spec (not developed yet) for
> Monasca, but the question would remain for us. One, two, or three years
> from now, what will happen if you, your team, or the people behind this
> spec/feature decide to leave the community? Will this feature be removed
> from Monasca too?
>
>
>
> On Wed, May 8, 2019 at 6:23 PM Joseph Davis <joseph.davis at suse.com> wrote:
>
> On 5/8/19 7:12 AM, openstack-discuss-request at lists.openstack.org wrote:
>
> Hello Trinh,
>
> Where does the meeting happen? Will it be via IRC Telemetry channel? Or, in
>
> the Etherpad (https://etherpad.openstack.org/p/telemetry-meeting-agenda)? I
>
> would like to discuss and understand a bit better the context behind
>
> the Telemetry
>
> events deprecation.
>
> Unfortunately, I have a conflict at that time and will not be able to
> attend.
>
> I do have a little bit of context on the Events deprecation to share.
>
> First, you will note the commit message from the commit [0] when Events
> were deprecated:
>
> "
>
> Deprecate event subsystem
>
> This subsystem has never been finished and is not maintained.
>
> Deprecate it for future removal.
>
> "
>
> I got the impression from jd at the time that there were a number of
> features in Telemetry,
>
> including Panko, that were not really "finished" and that the engineers
> who had worked on them
>
> had moved on to other things, so the features had become unsupported.  In
> late 2018 there was
>
> an effort to clean up things that were not well maintained or didn't fit
> the direction of Telemetry.
>
> See also:
> https://julien.danjou.info/lessons-from-openstack-telemetry-deflation/
>
>
>
> Events is one feature that often gets requested, but the use cases and
> demand for it are not expressed
>
> strongly or well understood by most people.  If the Telemetry project has
> demand to de-deprecate
>
> Event handling (including Panko), I'd suggest a review of the requirements
> for event handling and
>
> possibly choosing a champion for maintaining the Panko service.
>
>
>
> Also note: over in Monasca we have a spec [1] for handling Events
> ingestion which I hope we will be
>
> completing in Train.  Contributions and comments welcome. :)
>
>
>
> joseph
>
> [0]
> https://github.com/openstack/ceilometer/commit/8a0245a5b3e1357d35ad6653be37ca01176577e4
>
> [1]
> https://github.com/openstack/monasca-specs/blob/master/specs/stein/approved/monasca-events-listener.rst
>
>
>
> On Wed, May 8, 2019 at 12:19 AM Trinh Nguyen <dangtrinhnt at gmail.com> <dangtrinhnt at gmail.com> wrote:
>
>
>
> Hi team,
>
>
>
> As planned, we will have a team meeting at 02:00 UTC, May 9th on
>
> #openstack-telemetry to discuss what we gonna do for the next milestone
>
> (Train-1) and continue what we left off from the last meeting.
>
>
>
> I put here [1] the agenda thinking that it should be fine for an hour
>
> meeting. If you have anything to talk about, please put it there too.
>
>
>
> [1] https://etherpad.openstack.org/p/telemetry-meeting-agenda
>
>
>
>
>
> Bests,
>
>
>
> --
>
> ****Trinh Nguyen**
>
> *www.edlab.xyz <https://www.edlab.xyz> <https://www.edlab.xyz>*
>
>
>
>
>
>
>
> --
>
> Rafael Weingärtner
>


-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190509/95795ec2/attachment-0001.html>