<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 5/8/19 5:45 PM, Rafael Weingärtner
wrote:</div>
<snip><br>
<blockquote type="cite"
cite="mid:CAG97racasmxqSme=Wbfx4HP0ixUeu82FK-QbA4UFTb6OqfNN0Q@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>Thanks for the reply Joseph, <br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
</div>
</div>
</div>
</div>
</blockquote>
<p>Yeah, the history of Telemetry is a bit unusual in how it
developed, and I could give editorials and opinions about
decisions that were made and how well they worked in the
community, but I'll save that for another time. I will say that
communication with the community could have been better. And
while I think that simplifying Ceilometer was a good choice at the
time when the number of contributors was dwindling, I agree that
cutting out a feature that is being used by users is not how
OpenStack ought to operate. And now I'm starting to give opinions
so I'll stop.<br>
</p>
<p>I will say that it may be beneficial to the Telemetry project if
you can write out your use case for the Telemetry stack and
describe why you want Events to be captured and how you will use
them. Describe how they important to your billing solution (*),
and if you are matching the event notifications up with other
metering data. You can discuss with the team in the meeting if
that use case and set of requirements goes in Storyboard or
elsewhere.<br>
</p>
<p>(*) I am curious if you are using CloudKitty or another solution.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAG97racasmxqSme=Wbfx4HP0ixUeu82FK-QbA4UFTb6OqfNN0Q@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>Why is that important for us?<br>
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. <br>
</div>
</div>
</div>
</div>
</blockquote>
<p>I'm really glad you recognize the benefits of contributing back
to the community. It gives me hope. :)<br>
</p>
<snip><br>
<blockquote type="cite"
cite="mid:CAG97racasmxqSme=Wbfx4HP0ixUeu82FK-QbA4UFTb6OqfNN0Q@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>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? <br>
</div>
</div>
</div>
</div>
</blockquote>
<p>Developers leaving the community is a normal part of the
lifecycle, so I think you would agree that part of having a
healthy project is ensuring that when that happens the project can
go on. Monasca has already seen a number of developers come and
go, and will continue on for the foreseeable future. That is part
of why we wrote a spec for the events-listener, so that if needed
the work could change hands and continue with context. We try to
plan and get cross-company agreement in the community. Of course,
there are priorities and trade-offs and limits on developers, but
Monasca and OpenStack seem to do a good job of being 'open' about
it.<br>
</p>
<p><snip></p>
<blockquote type="cite"
cite="mid:CAG97racasmxqSme=Wbfx4HP0ixUeu82FK-QbA4UFTb6OqfNN0Q@mail.gmail.com"><br>
-- <br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">Rafael Weingärtner</div>
</div>
</blockquote>
<p><br>
</p>
<p>joseph<br>
</p>
</body>
</html>