Open Stack

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 
more forgiving, though with its own perils. I am reminded of this 
session, in which Jay was involved, at my first OpenStack summit: 
http://essexdesignsummit.sched.org/event/66f38d3bb4a1b8b169b81179e7f03215#.U_ZLI3Wx02Q

As for why projects have a desire to be blessed, I suspect in many cases 
it is because the OpenStack brand will attract contributors to their 
project.

  -David


>
> in my mind, the goal of the programs is to encourage collaboration 
> from projects with the same focus (whether they overlap or not). that 
> way, even if there's differences in goal/implementation, there's a 
> common space between them so users can easily decide. also, hopefully 
> with the collaboration, it'll help teams realise that certain problems 
> have already been solved and certain parts of code can be shared 
> rather than having project x, y, and z all working in segregated 
> streams, racing as fast as they can to claim supremacy (how you'd 
> decide is another mess) and then n number of months/years later we 
> decide to throw away (tens/hundreds) of thousands of person hours of 
> work because we just created massive projects that overlap.
>
> suggestion: maybe it's better to drop the branding codenames and just 
> refer to everything as their generic feature? ie. identity, telemetry, 
> orchestration, etc...
>
> cheers,
> /gord/
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140821/0a2a6ae0/attachment.html>