Open Stack

> On Apr 30, 2015, at 10:54 AM, Clint Byrum <clint at fewbar.com> wrote:
> 
> Excerpts from John Dickinson's message of 2015-04-30 09:40:02 -0700:
>> Swift is a scalable and durable storage engine for storing unstructured data. It's been proven time and time again in production in clusters all over the world.
>> 
>> We in the Swift developer community are constantly looking for ways to improve the codebase and deliver a better quality codebase to users everywhere. During the past year, the Rackspace Cloud Files team has been exploring the idea of reimplementing parts of Swift in Go. Yesterday, they released some of this code, called "hummingbird", for the first time. It's been proposed to a "feature/hummingbird" branch in Swift's source repo.
>> 
>> https://review.openstack.org/#/c/178851
>> 
>> I am very excited about this work being in the greater OpenStack Swift developer community. If you look at the patch above, you'll see that there are various parts of Swift reimplemented in Go. During the next six months (i.e. before Tokyo), I would like us to answer this question:
>> 
>> What advantages does a compiled-language object server bring, and do they outweigh the costs of using a different language?
>> 
>> 
>> Of course, there are a ton of things we need to explore on this topic, but I'm happy that we'll be doing it in the context of the open community instead of behind closed doors. We will have a fishbowl session in Vancouver on this topic. I'm looking forward to the discussion.
>> 
> 
> First, great job getting this out there at such an early stage. It's not
> an easy thing to decide when is right to bring something out into the
> light.
> 
> I would hope we can have many discussions on the mailing list first,
> as it is so broad in scope, every single developer would have interest
> in it, and unless we commandeer the plenary space, we probably won't
> be very comfortable stacked 6 high in a fishbowl room. ;)
> 
> Some points I'd like to see discussed here, in no particular order:
> 
> * I'd also think that we need to open this up to the operators too,
>  as python was chosen to be friendly to ops as well. Go is pretty ops
>  friendly too, so I don't think it would be a problem, but I think this
>  needs to be shared with operators before getting too far down the
>  road.
> 
> * Hummingbird claims to be an attempt to "improve performance
>  dramatically". I wonder if there was any attempt to use pypy to
>  achieve that with the existing code base, and if you could publicize
>  the results of such an attempt. If not, I think it would be quite
>  interesting to see comparisons and worthwhile to attempt a pypy vs.
>  cpython vs. hummingbird comparison.
> 
> * Even if the performance is better, will the maturity be regained
>  quick enough to have that matter? There are some past lessons to be
>  learned here: [1]
> 
> * Go's import and build system is rather odd. Python's weird distribution
>  issues are at least well known in the OpenStack community. This is
>  actually the main reason I've never gravitated toward Go, as I feel
>  it is trying to be magical rather than logical. I imagine there are
>  others who are also nervous about that.
> 
> * +1 for compiled languages that are less-daunting than say C++, but
>  still help find problems early. Anybody up for a Rust version too? ;-)

You raise a lot of good questions, and I can think of about a dozen more. Now that we see this in the open community, we can start talking about it. There don't need to be 1000 cooks in the kitchen, though. We'll be going over it in Vancouver and in the normal Swift dev community channels. Right now there are more questions than answers. We'll answer them.

To your first point, yes, operators are a huge part. I know that the Cloud Files devs are themselves responsible for maintaining production clusters, as are most of the active contributors to Swift. I'm confident that Swift will continue to be something that continues to be operator-friendly.

I'm excited to see what's happening, and we, the Swift community, will continue to deliver high-quality, tested, scalable, manageable code for object storage.

--John



> 
> [1] http://www.joelonsoftware.com/articles/fog0000000069.html
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150430/ac680312/attachment.pgp>