cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <Edison...@citrix.com>
Subject RE: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?
Date Mon, 15 Jul 2013 17:12:32 GMT
The 4.1 swift does support >5GB upload, AFAIK, as it uses python swift client, which can
support that. So I'll reuse whatever code we have in 4.1.

From: John Burwell [mailto:jburwell@basho.com]
Sent: Monday, July 15, 2013 8:47 AM
To: dev@cloudstack.apache.org
Cc: Edison Su
Subject: Re: Swift in 4.2 is broken, anybody wants it to be supported in 4.2?

All,

The openstack-java-client [1] looks to include a decent Swift client (a tutorial[2] is also
available).  It is also Apache v2 licensed.  From my cursory review, it doesn't appear to
support HTTP chunking (i.e. support for > 5GB objects) or progress reporting.  However,
the 4.1.x Swift integration does not support these features.  As such, it could be a good
starting point to provide parity with the current Swift integration facilities.

In general, I would much prefer using a purpose built client than an abstraction layer like
jclouds for this type of work.  We have a set of storage abstractions and adapting them to
another set of storage abstractions just feels a bit ungainly.  I think we could modify the
openstack-java-client to include the missing features and end with much more maintainable
result.

Thanks,
-John

[1]: https://github.com/woorea/openstack-java-sdk
[2]: https://github.com/woorea/openstack-java-sdk/wiki/Swift-Tutorial

On Jul 15, 2013, at 10:24 AM, Chip Childers <chip.childers@sungard.com<mailto:chip.childers@sungard.com>>
wrote:


On Fri, Jul 12, 2013 at 07:08:41PM -0600, Mike Tutkowski wrote:

So, I haven't been following this thread in detail, but was curious: If
it's too much work to fix this by the end of the month (code freeze), what
are we planning on doing (moving 4.2 back or allowing this feature to not
exist in 4.2)?

I'm personally not happy either way, but I'd much rather not break
existing environments in a new release on purpose.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message