Open Stack

On 5/8/19 5:45 PM, Rafael Weingärtner wrote:
<snip>
> 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).
>
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.

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.

(*) I am curious if you are using CloudKitty or another solution.


> 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.

I'm really glad you recognize the benefits of contributing back to the 
community.  It gives me hope. :)

<snip>
>
> 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?

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.

<snip>

>
> -- 
> Rafael Weingärtner


joseph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190508/4269febc/attachment.html>