On 08/21/2014 04:12 PM, Clint Byrum wrote:
Excerpts from David Kranz's message of 2014-08-21 12:45:05 -0700:
On 08/21/2014 02:39 PM, gordon chung wrote:
The point I've been making is
that by the TC continuing to bless only the Ceilometer project as the
OpenStack Way of Metering, I think we do a disservice to our users by
picking a winner in a space that is clearly still unsettled.
can we avoid using the word 'blessed' -- it's extremely vague and
seems controversial. from what i know, no one is being told project
x's services are the be all end all and based on experience, companies
(should) know this. i've worked with other alternatives even though i
contribute to ceilometer.
Totally agree with Jay here, I know people who gave up on trying to
get any official project around deployment because they were told they
had to do it under the TripleO umbrella
from the pov of a project that seems to be brought up constantly and
maybe it's my naivety, i don't really understand the fascination with
branding and the stigma people have placed on
non-'openstack'/stackforge projects. it can't be a legal thing because
i've gone through that potential mess. also, it's just as easy to
contribute to 'non-openstack' projects as 'openstack' projects (even
easier if we're honest).
Yes, we should be honest. The "even easier" part is what Sandy cited as
the primary motivation for pursuing stacktach instead of ceilometer.
I think we need to consider the difference between why OpenStack wants
to bless a project, and why a project might want to be blessed by
OpenStack. Many folks believe that for OpenStack to be successful it
needs to present itself as a stack that can be tested and deployed, not
a sack of parts that only the most extremely clever people can manage to
assemble into an actual cloud. In order to have such a stack, some code
(or, alternatively, dare I say API...) needs to be blessed. Reasonable
debates will continue about which pieces are essential to this stack,
and which should be left to deployers, but metering was seen as such a
component and therefore something needed to be blessed. The hope was
that every one would jump on that and make it great but it seems that
didn't quite happen (at least yet).
Though Open Source has many advantages over proprietary development, the
ability to choose a direction and marshal resources for efficient
delivery is the biggest advantage of proprietary development like what
AWS does. The TC process of blessing is, IMO, an attempt to compensate
for that in an OpenSource project. Of course if the wrong code is
blessed, the negative impact can be significant. Blessing APIs would be
Hm, I wonder if the only difference there is when AWS blesses the wrong
thing, they evaluate the business impact, and respond by going in a
different direction, all behind closed doors. The shame is limited to
that inner circle.
It is only limited to the inner circle if the "wrong thing" had no
public api in wide use. The advantage of blessing apis rather than
implementations is that mistakes can be corrected. I realize many people
hate that idea.
Here, with full transparency, calling something "the wrong thing" is
pretty much public humiliation for the team involved.
So it stands to reason that we shouldn't call something "the right
thing" if we aren't comfortable with the potential public shaming.
Of course not, and no one would argue that we should. The question being
debated is whether the benefits of choosing wisely are worth the risk of
choosing wrongly, as compared to the different-in-nature risks of not
choosing at all. Not so easy to answer IMO.
-David
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
