Open Stack

Agree. Instrumenting the code is the most efficient and recommended way 
to monitor the applications. We have discussed it during the 
Self-healing SIG PTG session last week.

The problem is that telemetry topic is not and never will be high 
priority for individual projects so the coordination effort from 
community is required here. I thinks this is one of the areas where 
Telemetry and Monasca teams could work together on.

Cheers
Witek


On 5/9/19 9:24 AM, Tim Bell 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 
> <mailto:joseph.davis at suse.com>> wrote:
> 
>     On 5/8/19 7:12 AM, openstack-discuss-request at lists.openstack.org
>     <mailto: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>  <mailto: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 <http://www.edlab.xyz>
>             <https://www.edlab.xyz> <https://www.edlab.xyz>*
> 
> 
> 
> -- 
> 
> Rafael Weingärtner
>