Open Stack

On 19/11/12 22:18, Boris Renski Jr. wrote:
> For instance, similar to Quantum, Swift could have been designed as an API
> centric service with implementations as plug-ins; but it is not. And largely
> due to the history of how OpenStack evolved, Swift now became the monopoly
> implementation on object store, indefinitely enjoying core project status.
> It is not unlikely that Swift could become less active and its opinionated
> architecture - less relevant to the newer paradigms of storage. More
> importantly, because something like Swift is core, nobody in the community
> would even consider developing a different, competing implementation....
>
> I am not trying to pick on Swift in particular (so John, don't get mad) but
> am using it to illustrate a scenario.

You appear to be thinking about Swift as a particular collection of 
code, and IMHO that is a mistake. Swift *has* a bunch of code, but Swift 
*is* a community.

There is no reason that the Swift architecture could not move toward a 
plugin model, and arguably they have been right not to do so before now 
since an abstraction with only one implementation is rarely a good 
abstraction.

However, anybody wanting the push that kind of code change is going to 
need to have the support of the Swift community. That support will not 
be forthcoming unless the change protects the interests of the existing 
Swift community (in particular, that probably means providing the 
existing functionality as a plugin with a simple migration path, not 
impacting maintainability, and so on).

So yes, blessing a project as an official part of OpenStack is 
inherently more conservative than leaving users to select from a random 
collection of freewheeling projects, and that is exactly the point of 
OpenStack. It gives members of the community confidence that things 
won't change drastically without their input, which is particularly 
important in deployments where multiple services are integrated (and 
that is most of them).

> 1. We can say we don't care about the rigidity of coupling between API and
> implementation in general. All we care about is if the project is mature
> enough and if it solves a substantial IaaS problem.... in that case we need
> to have a mechanism to deprecate projects from core when a particular
> implementation is no longer optimal or if the project becomes inactive.

We should deprecate a project from Core if and only if its community is 
moribund (most likely because there's nobody around to maintain it).

cheers,
Zane.