Edison, My bad thing for the Python client oversight and +1 to simply carrying the 4.1.x implementation forward. I have added an enhancement ticket [1] for post-4.2.0 to move a Java native client when we have the proper time to assess/contribute to upstream projects.
Thanks, -John [1]: https://issues.apache.org/jira/browse/CLOUDSTACK-3536 On Jul 15, 2013, at 1:12 PM, Edison Su <edison...@citrix.com> wrote: > 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:jburw...@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.child...@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. >
