Open Stack

On 09/24/2014 02:48 PM, Clint Byrum wrote:
> Excerpts from Robert Collins's message of 2014-09-23 21:14:47 -0700:
>> No one helped me edit this :)
>>
>> http://rbtcollins.wordpress.com/2014/09/24/what-poles-for-the-tent/
>>
>> I hope I haven't zoned out and just channelled someone else here ;)
>>
> This sounds like "API's are what matters." You did spend some time
> working with Simon Wardley, didn't you? ;)
>
> I think it's a sound argument, but I'd like to banish the term "reference
> implementation" from any discussions around what OpenStack, as a project,
> delivers. It has too many negative feelings wrapped up in it.
>
> I also want to call attention to how what you describe feels an awful
> lot like POSIX to me. Basically offering guarantees of API compatibility,
> but then letting vendors run wild around and behind it.
>
> I'm not sure if that is a good thing, or a bad thing. I do, however,
> think if we can avoid a massive vendor battle that involves multiple
> vendors pushing multiple implementations, we will save our companies a
> lot of money, and our users will get what they need sooner.
I like what Rob had to say here, and have expressed similar views. 
Having competition between implementations is good for every one (except 
for the losers) if that competition takes place in a way that shields 
users and the ecosystem from the aftermath of such competition. That is 
what standards, defined apis, whetever we want to call it, is all about. 
By analogy, competition by electronics companies around who can make the 
best performing blu-ray player with the most features is a good thing 
for users and that ecosystem. Competition about whether the ecosystem 
should use blu-ray or HD DVD, not so much: 
http://en.wikipedia.org/wiki/High_definition_optical_disc_format_war.

This is what I see as the main virtue of the TC blessing things as "the 
one OpenStack way to do X". There is also the potential of efficiency if 
more people contribute to the same project that is doing X as compared 
to multiple projects doing X. But as we have seen, that efficiency is 
only realized if X turns out to be "the right thing". There is no 
particular reason to think the TC will be great at picking winners.

Blessing apis, though difficult, would have huge benefit and provide 
more room for leeway and experimentation. Blessing code, before it has 
been proven in the real world, is the worst of all worlds when it turns 
out to be wrong.

I believe our scale problems can be addressed by thoughtful 
decentralization and I hope we move in that direction, and in terms of 
how many pieces of the "run a real cloud" we have in our tent, we may 
have shot too high. But some of the recent proposals to move to an 
extreme in the other direction would be  a mistake IMO. To be important, 
and be competitive with non-OpenStack cloud solutions, we need to 
provide a critical mass so that most other interesting things can glom 
on and form a larger ecosystem.

  -David


>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev