[jira] [Commented] (JCLOUDS-1380) Multiple IT/Live test failures with Openstack Swift
[
https://issues.apache.org/jira/browse/JCLOUDS-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16363944#comment-16363944
]
Cservenak, Tamas commented on JCLOUDS-1380:
---
Built IT/Live on 2.0.x branch too (992e60d82dc979c26a668079adda614e234434df):
{{Tests run: 155, Failures: 36, Errors: 0, Skipped: 36}}
TIA
> Multiple IT/Live test failures with Openstack Swift
> ---
>
> Key: JCLOUDS-1380
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1380
> Project: jclouds
> Issue Type: Test
>Reporter: Cservenak, Tamas
>Priority: Major
>
> I have access to Openstack Swift instance and am planning to use JClouds to
> access it. Hence, just "for fun" I tried the IT/Live test suite against swift
> instance, and got several test failures.
> {{Tests run: 165, Failures: 36, Errors: 0, Skipped: 35}}
> Built the *master* branch of jclouds
> (88c84af8788116be2b1f492c3314e07b493dc6f2).
> How can I contribute to swift api improvements? Should I share the
> surefire-reports folder with failure details (is it enough? would it contain
> some sensitive data, ie. swift credentials/URLs I used?)
> Since am toying with 2.0.3 version, am planning to try the 2.0.x branch too.
> TIA
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCLOUDS-1380) Multiple IT/Live test failures with Openstack Swift
[
https://issues.apache.org/jira/browse/JCLOUDS-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16364204#comment-16364204
]
Cservenak, Tamas commented on JCLOUDS-1380:
---
Re swift version: to my surprise, turned out I am actually accessing Ceph via
radosgw over Swift API (10.2.7 + patches), so please consider that while
evaluating 2.0.x branch tests.
> Multiple IT/Live test failures with Openstack Swift
> ---
>
> Key: JCLOUDS-1380
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1380
> Project: jclouds
> Issue Type: Test
>Reporter: Cservenak, Tamas
>Priority: Major
> Attachments: openstack-swift-2.0.x.txt
>
>
> I have access to Openstack Swift instance and am planning to use JClouds to
> access it. Hence, just "for fun" I tried the IT/Live test suite against swift
> instance, and got several test failures.
> {{Tests run: 165, Failures: 36, Errors: 0, Skipped: 35}}
> Built the *master* branch of jclouds
> (88c84af8788116be2b1f492c3314e07b493dc6f2).
> How can I contribute to swift api improvements? Should I share the
> surefire-reports folder with failure details (is it enough? would it contain
> some sensitive data, ie. swift credentials/URLs I used?)
> Since am toying with 2.0.3 version, am planning to try the 2.0.x branch too.
> TIA
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCLOUDS-1380) Multiple IT/Live test failures with Openstack Swift
[
https://issues.apache.org/jira/browse/JCLOUDS-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16364120#comment-16364120
]
Cservenak, Tamas commented on JCLOUDS-1380:
---
Hi [~andreaturli], yes I can attach both logs, but need to anonymize them, as I
see, full auth/url/pwd stuff is present in them...
> Multiple IT/Live test failures with Openstack Swift
> ---
>
> Key: JCLOUDS-1380
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1380
> Project: jclouds
> Issue Type: Test
>Reporter: Cservenak, Tamas
>Priority: Major
>
> I have access to Openstack Swift instance and am planning to use JClouds to
> access it. Hence, just "for fun" I tried the IT/Live test suite against swift
> instance, and got several test failures.
> {{Tests run: 165, Failures: 36, Errors: 0, Skipped: 35}}
> Built the *master* branch of jclouds
> (88c84af8788116be2b1f492c3314e07b493dc6f2).
> How can I contribute to swift api improvements? Should I share the
> surefire-reports folder with failure details (is it enough? would it contain
> some sensitive data, ie. swift credentials/URLs I used?)
> Since am toying with 2.0.3 version, am planning to try the 2.0.x branch too.
> TIA
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCLOUDS-1380) Multiple IT/Live test failures with Openstack Swift
[
https://issues.apache.org/jira/browse/JCLOUDS-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cservenak, Tamas updated JCLOUDS-1380:
--
Attachment: openstack-swift-2.0.x.txt
> Multiple IT/Live test failures with Openstack Swift
> ---
>
> Key: JCLOUDS-1380
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1380
> Project: jclouds
> Issue Type: Test
>Reporter: Cservenak, Tamas
>Priority: Major
> Attachments: openstack-swift-2.0.x.txt
>
>
> I have access to Openstack Swift instance and am planning to use JClouds to
> access it. Hence, just "for fun" I tried the IT/Live test suite against swift
> instance, and got several test failures.
> {{Tests run: 165, Failures: 36, Errors: 0, Skipped: 35}}
> Built the *master* branch of jclouds
> (88c84af8788116be2b1f492c3314e07b493dc6f2).
> How can I contribute to swift api improvements? Should I share the
> surefire-reports folder with failure details (is it enough? would it contain
> some sensitive data, ie. swift credentials/URLs I used?)
> Since am toying with 2.0.3 version, am planning to try the 2.0.x branch too.
> TIA
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JCLOUDS-1380) Multiple IT/Live test failures with Openstack Swift
Cservenak, Tamas created JCLOUDS-1380:
-
Summary: Multiple IT/Live test failures with Openstack Swift
Key: JCLOUDS-1380
URL: https://issues.apache.org/jira/browse/JCLOUDS-1380
Project: jclouds
Issue Type: Test
Reporter: Cservenak, Tamas
I have access to Openstack Swift instance and am planning to use JClouds to
access it. Hence, just "for fun" I tried the IT/Live test suite against swift
instance, and got several test failures.
{{Tests run: 165, Failures: 36, Errors: 0, Skipped: 35}}
Built the *master* branch of jclouds (88c84af8788116be2b1f492c3314e07b493dc6f2).
How can I contribute to swift api improvements? Should I share the
surefire-reports folder with failure details (is it enough? would it contain
some sensitive data, ie. swift credentials/URLs I used?)
Since am toying with 2.0.3 version, am planning to try the 2.0.x branch too.
TIA
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCLOUDS-1380) Multiple IT/Live test failures with Openstack Swift
[
https://issues.apache.org/jira/browse/JCLOUDS-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16365545#comment-16365545
]
Cservenak, Tamas commented on JCLOUDS-1380:
---
[~gaul] Thanks for advice, am newbie with jclouds and Ceph in general.
Your comment made me run s3 api IT/Live tests too against our s3 api on 2.0.3
branch (992e60d82dc979c26a668079adda614e234434df):
{{Tests run: 144, Failures: 13, Errors: 0, Skipped: 10}}
Is better, so it really seems s3 is "better supported" than swift api (where
error rate I got was 1/4+ of all tests).
> Multiple IT/Live test failures with Openstack Swift
> ---
>
> Key: JCLOUDS-1380
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1380
> Project: jclouds
> Issue Type: Test
>Reporter: Cservenak, Tamas
>Priority: Major
> Attachments: openstack-swift-2.0.x.txt
>
>
> I have access to Openstack Swift instance and am planning to use JClouds to
> access it. Hence, just "for fun" I tried the IT/Live test suite against swift
> instance, and got several test failures.
> {{Tests run: 165, Failures: 36, Errors: 0, Skipped: 35}}
> Built the *master* branch of jclouds
> (88c84af8788116be2b1f492c3314e07b493dc6f2).
> How can I contribute to swift api improvements? Should I share the
> surefire-reports folder with failure details (is it enough? would it contain
> some sensitive data, ie. swift credentials/URLs I used?)
> Since am toying with 2.0.3 version, am planning to try the 2.0.x branch too.
> TIA
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCLOUDS-1380) Multiple IT/Live test failures with Openstack Swift
[
https://issues.apache.org/jira/browse/JCLOUDS-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16365905#comment-16365905
]
Cservenak, Tamas commented on JCLOUDS-1380:
---
[~gaul] Completely agree and thanks for help so far.
> Multiple IT/Live test failures with Openstack Swift
> ---
>
> Key: JCLOUDS-1380
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1380
> Project: jclouds
> Issue Type: Test
>Reporter: Cservenak, Tamas
>Assignee: Andrew Gaul
>Priority: Major
> Attachments: openstack-swift-2.0.x.txt
>
>
> I have access to Openstack Swift instance and am planning to use JClouds to
> access it. Hence, just "for fun" I tried the IT/Live test suite against swift
> instance, and got several test failures.
> {{Tests run: 165, Failures: 36, Errors: 0, Skipped: 35}}
> Built the *master* branch of jclouds
> (88c84af8788116be2b1f492c3314e07b493dc6f2).
> How can I contribute to swift api improvements? Should I share the
> surefire-reports folder with failure details (is it enough? would it contain
> some sensitive data, ie. swift credentials/URLs I used?)
> Since am toying with 2.0.3 version, am planning to try the 2.0.x branch too.
> TIA
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JCLOUDS-1385) Possible inconsistency with list operations w/ and w/o metadata
Cservenak, Tamas created JCLOUDS-1385: - Summary: Possible inconsistency with list operations w/ and w/o metadata Key: JCLOUDS-1385 URL: https://issues.apache.org/jira/browse/JCLOUDS-1385 Project: jclouds Issue Type: Bug Reporter: Cservenak, Tamas When you do a "list" on a folder, depending do you ask for blob metadata or not, you get different results. If you DO ask for metadata too, you will get only blobs in result, while if you DO NOT ask for metadata, you will get blobs and sub-folders too in result. I suspect that the reason of this is the predicate filtering (input.getType() == StorageType.BLOB) in class FetchBlobMetadata. I guess it may be optimised to not call into blobstore.blobMetadata for input.getType() != StorageType.BLOB? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCLOUDS-1384) Header ordering broken in azureblob SharedKeyLiteAuthentication
[ https://issues.apache.org/jira/browse/JCLOUDS-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cservenak, Tamas updated JCLOUDS-1384: -- Summary: Header ordering broken in azureblob SharedKeyLiteAuthentication (was: Header ordering broken in azure SharedKeyLiteAuthentication) > Header ordering broken in azureblob SharedKeyLiteAuthentication > --- > > Key: JCLOUDS-1384 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1384 > Project: jclouds > Issue Type: Bug >Reporter: Cservenak, Tamas >Priority: Major > > SharedKeyLiteAuthentication first orders headers lexicographically, then > lowercase them, which may produce invalid ordering (server will sign > different string than jclouds client). > According to azure, lowercase all headers then sort them: > https://docs.microsoft.com/en-us/rest/api/storageservices/authentication-for-the-azure-storage-services#Constructing_Element -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCLOUDS-1385) Possible inconsistency with BlobStore list operations w/ and w/o metadata
[ https://issues.apache.org/jira/browse/JCLOUDS-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cservenak, Tamas updated JCLOUDS-1385: -- Component/s: jclouds-blobstore > Possible inconsistency with BlobStore list operations w/ and w/o metadata > -- > > Key: JCLOUDS-1385 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1385 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Reporter: Cservenak, Tamas >Priority: Major > > When you do a "list" on a folder, depending do you ask for blob metadata or > not, you get different results. If you DO ask for metadata too, you will get > only blobs in result, while if you DO NOT ask for metadata, you will get > blobs and sub-folders too in result. > I suspect that the reason of this is the predicate filtering (input.getType() > == StorageType.BLOB) in class FetchBlobMetadata. > I guess it may be optimised to not call into blobstore.blobMetadata for > input.getType() != StorageType.BLOB? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCLOUDS-1385) Possible inconsistency with BlobStore list operations w/ and w/o metadata
[ https://issues.apache.org/jira/browse/JCLOUDS-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cservenak, Tamas updated JCLOUDS-1385: -- Summary: Possible inconsistency with BlobStore list operations w/ and w/o metadata (was: Possible inconsistency with list operations w/ and w/o metadata) > Possible inconsistency with BlobStore list operations w/ and w/o metadata > -- > > Key: JCLOUDS-1385 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1385 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Reporter: Cservenak, Tamas >Priority: Major > > When you do a "list" on a folder, depending do you ask for blob metadata or > not, you get different results. If you DO ask for metadata too, you will get > only blobs in result, while if you DO NOT ask for metadata, you will get > blobs and sub-folders too in result. > I suspect that the reason of this is the predicate filtering (input.getType() > == StorageType.BLOB) in class FetchBlobMetadata. > I guess it may be optimised to not call into blobstore.blobMetadata for > input.getType() != StorageType.BLOB? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCLOUDS-1385) Possible inconsistency with BlobStore list operations w/ and w/o metadata
[ https://issues.apache.org/jira/browse/JCLOUDS-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cservenak, Tamas updated JCLOUDS-1385: -- Labels: blobstore (was: ) > Possible inconsistency with BlobStore list operations w/ and w/o metadata > -- > > Key: JCLOUDS-1385 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1385 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Reporter: Cservenak, Tamas >Priority: Major > Labels: blobstore > > When you do a "list" on a folder, depending do you ask for blob metadata or > not, you get different results. If you DO ask for metadata too, you will get > only blobs in result, while if you DO NOT ask for metadata, you will get > blobs and sub-folders too in result. > I suspect that the reason of this is the predicate filtering (input.getType() > == StorageType.BLOB) in class FetchBlobMetadata. > I guess it may be optimised to not call into blobstore.blobMetadata for > input.getType() != StorageType.BLOB? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCLOUDS-1384) Header ordering broken in azureblob SharedKeyLiteAuthentication
[ https://issues.apache.org/jira/browse/JCLOUDS-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cservenak, Tamas updated JCLOUDS-1384: -- Labels: azureblob signing (was: ) > Header ordering broken in azureblob SharedKeyLiteAuthentication > --- > > Key: JCLOUDS-1384 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1384 > Project: jclouds > Issue Type: Bug >Reporter: Cservenak, Tamas >Priority: Major > Labels: azureblob, signing > > SharedKeyLiteAuthentication first orders headers lexicographically, then > lowercase them, which may produce invalid ordering (server will sign > different string than jclouds client). > According to azure, lowercase all headers then sort them: > https://docs.microsoft.com/en-us/rest/api/storageservices/authentication-for-the-azure-storage-services#Constructing_Element -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCLOUDS-1380) Multiple IT/Live test failures with Openstack Swift
[
https://issues.apache.org/jira/browse/JCLOUDS-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cservenak, Tamas updated JCLOUDS-1380:
--
Attachment: (was: openstack-swift-2.0.x.txt)
> Multiple IT/Live test failures with Openstack Swift
> ---
>
> Key: JCLOUDS-1380
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1380
> Project: jclouds
> Issue Type: Test
>Reporter: Cservenak, Tamas
>Assignee: Andrew Gaul
>Priority: Major
>
> I have access to Openstack Swift instance and am planning to use JClouds to
> access it. Hence, just "for fun" I tried the IT/Live test suite against swift
> instance, and got several test failures.
> {{Tests run: 165, Failures: 36, Errors: 0, Skipped: 35}}
> Built the *master* branch of jclouds
> (88c84af8788116be2b1f492c3314e07b493dc6f2).
> How can I contribute to swift api improvements? Should I share the
> surefire-reports folder with failure details (is it enough? would it contain
> some sensitive data, ie. swift credentials/URLs I used?)
> Since am toying with 2.0.3 version, am planning to try the 2.0.x branch too.
> TIA
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCLOUDS-1384) Header ordering broken in azure SharedKeyLiteAuthentication
[ https://issues.apache.org/jira/browse/JCLOUDS-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369136#comment-16369136 ] Cservenak, Tamas commented on JCLOUDS-1384: --- UT representing the problem https://github.com/jclouds/jclouds/pull/1182 > Header ordering broken in azure SharedKeyLiteAuthentication > --- > > Key: JCLOUDS-1384 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1384 > Project: jclouds > Issue Type: Bug >Reporter: Cservenak, Tamas >Priority: Major > > SharedKeyLiteAuthentication first orders headers lexicographically, then > lowercase them, which may produce invalid ordering (server will sign > different string than jclouds client). > > According to azure, lowercase all headers then sort them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCLOUDS-1384) Header ordering broken in azure SharedKeyLiteAuthentication
[ https://issues.apache.org/jira/browse/JCLOUDS-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cservenak, Tamas updated JCLOUDS-1384: -- Description: SharedKeyLiteAuthentication first orders headers lexicographically, then lowercase them, which may produce invalid ordering (server will sign different string than jclouds client). According to azure, lowercase all headers then sort them: https://docs.microsoft.com/en-us/rest/api/storageservices/authentication-for-the-azure-storage-services#Constructing_Element was: SharedKeyLiteAuthentication first orders headers lexicographically, then lowercase them, which may produce invalid ordering (server will sign different string than jclouds client). According to azure, lowercase all headers then sort them. > Header ordering broken in azure SharedKeyLiteAuthentication > --- > > Key: JCLOUDS-1384 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1384 > Project: jclouds > Issue Type: Bug >Reporter: Cservenak, Tamas >Priority: Major > > SharedKeyLiteAuthentication first orders headers lexicographically, then > lowercase them, which may produce invalid ordering (server will sign > different string than jclouds client). > According to azure, lowercase all headers then sort them: > https://docs.microsoft.com/en-us/rest/api/storageservices/authentication-for-the-azure-storage-services#Constructing_Element -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JCLOUDS-1384) Header ordering broken in azure SharedKeyLiteAuthentication
Cservenak, Tamas created JCLOUDS-1384: - Summary: Header ordering broken in azure SharedKeyLiteAuthentication Key: JCLOUDS-1384 URL: https://issues.apache.org/jira/browse/JCLOUDS-1384 Project: jclouds Issue Type: Bug Reporter: Cservenak, Tamas SharedKeyLiteAuthentication first orders headers lexicographically, then lowercase them, which may produce invalid ordering (server will sign different string than jclouds client). According to azure, lowercase all headers then sort them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (JCLOUDS-1384) Header ordering broken in azureblob SharedKeyLiteAuthentication
[ https://issues.apache.org/jira/browse/JCLOUDS-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cservenak, Tamas closed JCLOUDS-1384. - Resolution: Duplicate > Header ordering broken in azureblob SharedKeyLiteAuthentication > --- > > Key: JCLOUDS-1384 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1384 > Project: jclouds > Issue Type: Bug >Reporter: Cservenak, Tamas >Priority: Major > Labels: azureblob, signing > > SharedKeyLiteAuthentication first orders headers lexicographically, then > lowercase them, which may produce invalid ordering (server will sign > different string than jclouds client). > According to azure, lowercase all headers then sort them: > https://docs.microsoft.com/en-us/rest/api/storageservices/authentication-for-the-azure-storage-services#Constructing_Element -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (JCLOUDS-1385) Possible inconsistency with BlobStore list operations w/ and w/o metadata
[ https://issues.apache.org/jira/browse/JCLOUDS-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cservenak, Tamas closed JCLOUDS-1385. - Resolution: Duplicate > Possible inconsistency with BlobStore list operations w/ and w/o metadata > -- > > Key: JCLOUDS-1385 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1385 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Reporter: Cservenak, Tamas >Priority: Major > > When you do a "list" on a folder, depending do you ask for blob metadata or > not, you get different results. If you DO ask for metadata too, you will get > only blobs in result, while if you DO NOT ask for metadata, you will get > blobs and sub-folders too in result. > I suspect that the reason of this is the predicate filtering (input.getType() > == StorageType.BLOB) in class FetchBlobMetadata. > I guess it may be optimised to not call into blobstore.blobMetadata for > input.getType() != StorageType.BLOB? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
