jclouds-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Gaul <g...@apache.org>
Subject Re: Swift Multipart upload SLO or DLO
Date Wed, 05 Apr 2017 19:34:22 GMT
Sorry I cannot help you debug your Swift configuration.  jclouds SLO
works with properly configured public providers like Rackspace so I
suggest exploring the differences between it and your local setup.
jclouds 2.0.0 does not support DLO and the older jclouds 1.9.1 Swift
implementation works differently so I do not recommend using it.  I did
not mention a test case and do not understand your last comment.

On Wed, Apr 05, 2017 at 10:20:15AM +0000, Archana C wrote:
> Hi
> 
> 1. Do you enable "SLO" in swift as required filter (swift/proxy/server.py)       
required_filters = [
>     {'name': 'catch_errors'},
>     {'name': 'gatekeeper',
>      'after_fn': lambda pipe: (['catch_errors']
>                                if pipe.startswith('catch_errors')
>                                else [])},
>     {'name': 'dlo', 'after_fn': lambda _junk: [
>         'staticweb', 'tempauth', 'keystoneauth',
>         'catch_errors', 'gatekeeper', 'proxy_logging']}]
> Should this be slo for static large object upload ? Or is there any thing to be done
to treat request as SLO.
> 
> 2. I noticed  that "DLO" is enabled as a default filter (confirmed from swift logs),
hence adding header "X-Object-Manifest" only helped get correct Content-length.
> 3. I compared 1.9.1 jcloluds CommonSwiftClient.java:putObjectManifest with jclouds 2.0
StaticLargeObject.java:replaceManifest, I figured out that "X-Object-Manifest" is used as
required in jclouds 1.9.1 and that has been omitted in 2.0 
> Please share sample test case that you mentioned 
> RegardsArchana 
> 
>     On Wednesday, 5 April 2017, 15:49, Archana C <carchana36@yahoo.co.uk> wrote:
>  
> 
>  Hi
> 
> 1. Do you enable "SLO" in swift as required filter (swift/proxy/server.py)       
required_filters = [
>     {'name': 'catch_errors'},
>     {'name': 'gatekeeper',
>      'after_fn': lambda pipe: (['catch_errors']
>                                if pipe.startswith('catch_errors')
>                                else [])},
>     {'name': 'dlo', 'after_fn': lambda _junk: [
>         'staticweb', 'tempauth', 'keystoneauth',
>         'catch_errors', 'gatekeeper', 'proxy_logging']}]
> Should this be slo for static large object upload ? Or is there any thing to be done
to treat request as SLO.
> 
> 2. I noticed  that "DLO" is enabled as a default filter (confirmed from swift logs),
hence adding header "X-Object-Manifest" only helped get correct Content-length.
> 3. I compared 1.9.1 jcloluds CommonSwiftClient.java:putObjectManifest with jclouds 2.0
StaticLargeObject.java:replaceManifest, I figured out that "X-Object-Manifest" is used as
required in jclouds 1.9.1 and that has been omitted in 2.0 
> Please share sample test case that you mentioned 
> RegardsArchana 
> 
>     On Tuesday, 4 April 2017, 23:39, Andrew Gaul <gaul@apache.org> wrote:
>  
> 
>  jclouds supports static large objects with Swift.  We could add support
> for dynamic objects but these have a number of caveats and differ from
> other providers.
> 
> On Tue, Apr 04, 2017 at 04:28:56PM +0000, Archana C wrote:
> > Hi 
> > 
> > Does jclouds 2.0.0 supports swift Static Large Object Upload (SLO) or Dynamic Large
Object Upload(DLO) ?
> > 
> > As per our observation,
> > 1. It looks like jClouds does SLO and not DLO.
> > 2. SLO requires no headers whereas DLO requires X-Object-Manifest as header while
manifest upload as mentioned in [1].
> > 
> > [1] https://docs.openstack.org/user-guide/cli-swift-large-object-creation.html
> > RegardsArchana
> > 
> 
> -- 
> Andrew Gaul
> http://gaul.org/
> 
> 
>    
> 
>    

-- 
Andrew Gaul
http://gaul.org/

Mime
View raw message