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 +, 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
> 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 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 +, 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/
