[jira] [Commented] (JCLOUDS-1132) Amazon AWS - Create Volume - query params reported as unrecognized
[ https://issues.apache.org/jira/browse/JCLOUDS-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15492679#comment-15492679 ] Felix Otto commented on JCLOUDS-1132: - Thanks Mihai, I will check it out! > Amazon AWS - Create Volume - query params reported as unrecognized > -- > > Key: JCLOUDS-1132 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1132 > Project: jclouds > Issue Type: Bug > Components: jclouds-compute >Affects Versions: 1.9.0, 1.9.2 > Environment: Amazon AWS EC2 management console >Reporter: Tusa Mihail Cristian > > Let say that I want to create a Volume that is encrypted. So, I set the > encrypted on "true"... in request query params apear "&Encrypted=true". In > this case the error that I got is: > UnknownParameterThe parameter > Encrypted is not > recognizedc874434a-b00e-425d-baf4-18087441603a > > instead it should be: "&Encrypted=1" as it is shown in Amazon docs: > http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateVolume.html > in Example/Sample request. The problems are also related with Volume Type. If > not specified than creates a standard volume but if anything specified (any > of valid Values: standard | io1 | gp2 | sc1 | st1 ) the same error with > unrecognized param is received. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (JCLOUDS-1132) Amazon AWS - Create Volume - query params reported as unrecognized
[ https://issues.apache.org/jira/browse/JCLOUDS-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15492679#comment-15492679 ] Felix Otto edited comment on JCLOUDS-1132 at 9/15/16 7:52 AM: -- Thanks Mihail, I will check it out! was (Author: felix.otto): Thanks Mihai, I will check it out! > Amazon AWS - Create Volume - query params reported as unrecognized > -- > > Key: JCLOUDS-1132 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1132 > Project: jclouds > Issue Type: Bug > Components: jclouds-compute >Affects Versions: 1.9.0, 1.9.2 > Environment: Amazon AWS EC2 management console >Reporter: Tusa Mihail Cristian > > Let say that I want to create a Volume that is encrypted. So, I set the > encrypted on "true"... in request query params apear "&Encrypted=true". In > this case the error that I got is: > UnknownParameterThe parameter > Encrypted is not > recognizedc874434a-b00e-425d-baf4-18087441603a > > instead it should be: "&Encrypted=1" as it is shown in Amazon docs: > http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateVolume.html > in Example/Sample request. The problems are also related with Volume Type. If > not specified than creates a standard volume but if anything specified (any > of valid Values: standard | io1 | gp2 | sc1 | st1 ) the same error with > unrecognized param is received. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jclouds/jclouds-labs] Pb compute api (#292)
alibazlamit commented on this pull request.
> +import org.jclouds.compute.domain.Hardware;
+import org.jclouds.compute.domain.Image;
+import org.jclouds.compute.domain.NodeMetadata;
+import org.jclouds.compute.domain.Volume;
+import org.jclouds.domain.Location;
+import org.jclouds.functions.IdentityFunction;
+import org.jclouds.lifecycle.Closer;
+import org.jclouds.location.suppliers.ImplicitLocationSupplier;
+import org.jclouds.location.suppliers.implicit.OnlyLocationOrFirstZone;
+import static org.jclouds.util.Predicates2.retry;
+
+public class ProfitBricksComputeServiceContextModule extends
+ComputeServiceAdapterContextModule {
+
+@Override
+protected void configure() {
@devcsrj can i use [this
](https://github.com/jclouds/jclouds/tree/master/providers/profitbricks)as a
reference?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/292
Re: [jclouds/jclouds-labs] fix azure-arm features live tests (#317)
@andreaturli pushed 3 commits. 79c8f32 add image publishers filter to AzureComputeServiceLiveTest eefa3bd add parser module to provider de2d18b fix checkstyle -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/jclouds/jclouds-labs/pull/317/files/9c9ae7e491b9636c1455c09d2c6f37933d4b7638..de2d18b992386ed07e9a1b88ecd7135145c5640a
Re: [jclouds/jclouds-labs] Pb compute api (#292)
@alibazlamit pushed 2 commits. f597512 pb-compue-api fix 0e73461 Merge branch 'pb-compute-api' of https://github.com/StackPointCloud/jclouds-labs into pb-compute-api -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/jclouds/jclouds-labs/pull/292/files/a6d5323cc613ecef69a605918bfc9b5ca4115bc5..0e73461ab465e08e012f9a266d8c3fed0d3d72a2
Re: [jclouds/jclouds-labs] Pb compute api (#292)
@alibazlamit pushed 1 commit. 9d66ce5 reverted deletion of file -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/jclouds/jclouds-labs/pull/292/files/0e73461ab465e08e012f9a266d8c3fed0d3d72a2..9d66ce5e8f044953082dec3934f2ef35a0c666ea
[jira] [Commented] (JCLOUDS-1166) Remove uses of the 'com.google.gson.internal' package
[
https://issues.apache.org/jira/browse/JCLOUDS-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15493053#comment-15493053
]
Andrew Phillips commented on JCLOUDS-1166:
--
_> what do you think about the custom bundle approach?_
[~nacx]: If we can make a new bundle using the Gson lib directly as the source,
and only including and exporting the relevant internal files, I think that
could work, yes - sounds like a good idea to me!
I'd be more hesitant about copying the files out and bundling them up
ourselves, as then I think there would be a risk that we end up with different
files in non-OSGi environments (where we would get the files straight from the
Gson JAR) vs. OSGi environments (where we would get our copies files from the
custom bundle).
Was the "shade straight from the Gson JAR" the approach you had in mind?
> Remove uses of the 'com.google.gson.internal' package
> -
>
> Key: JCLOUDS-1166
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1166
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-chef, jclouds-core
>Affects Versions: 1.9.2
>Reporter: Ignasi Barrera
> Labels: gson
>
> Starting from Gson 2.6, the {{com.google.gson.internal}} packages are no
> longer exported in the OSGi bundles. This makes it impossible to use jclouds
> in an OSGi environment if upgrading to such versions of Gson.
> There is no change to add the exports back for that package (see [this
> discussion|https://github.com/google/gson/pull/916]), so we should stop using
> those classes.
> See also: http://markmail.org/message/olgebygfgdy3hwtm
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [jclouds/jclouds-labs] Pb compute api (#292)
@alibazlamit pushed 1 commit. e108738 fix build -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/jclouds/jclouds-labs/pull/292/files/9d66ce5e8f044953082dec3934f2ef35a0c666ea..e108738c448cd76a519e62127b85e23dec454aa4
[jira] [Commented] (JCLOUDS-1166) Remove uses of the 'com.google.gson.internal' package
[
https://issues.apache.org/jira/browse/JCLOUDS-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15493070#comment-15493070
]
Ignasi Barrera commented on JCLOUDS-1166:
-
Yes, just patching the manifest as we've done with the jsch agentproxy
> Remove uses of the 'com.google.gson.internal' package
> -
>
> Key: JCLOUDS-1166
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1166
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-chef, jclouds-core
>Affects Versions: 1.9.2
>Reporter: Ignasi Barrera
> Labels: gson
>
> Starting from Gson 2.6, the {{com.google.gson.internal}} packages are no
> longer exported in the OSGi bundles. This makes it impossible to use jclouds
> in an OSGi environment if upgrading to such versions of Gson.
> There is no change to add the exports back for that package (see [this
> discussion|https://github.com/google/gson/pull/916]), so we should stop using
> those classes.
> See also: http://markmail.org/message/olgebygfgdy3hwtm
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [jclouds/jclouds-labs] Pb compute api (#292)
@alibazlamit pushed 1 commit. d32fb3c fixed license text -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/jclouds/jclouds-labs/pull/292/files/e108738c448cd76a519e62127b85e23dec454aa4..d32fb3c68b03bb5a28527a9f1402aa584e9601cf
Re: [jclouds/jclouds-labs] fix azure-arm features live tests (#317)
@nacx happy to share the live tests results, **but** it would be useful to merge first https://github.com/jclouds/jclouds-labs/pull/308 as it speed up the live tests significantely -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/317#issuecomment-247308864
[jira] [Updated] (JCLOUDS-1179) putBlob doesn't handle 401s
[ https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Howes updated JCLOUDS-1179: Affects Version/s: 2.0.0 > putBlob doesn't handle 401s > > > Key: JCLOUDS-1179 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1179 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.7.1, 2.0.0 > Environment: Keystone + Swift on OpenStack Havana > Ubuntu 12.04 >Reporter: Nick Howes > Labels: swift > > After the token used by jclouds expires, subsequent `putBlob` requests to > swift fail with 401. > Unlike creations of temporary urls, the `putBlob` command does not resolve > this by `POST`ing to keystone, but instead tries a few times to `PUT` the > blob to swift. Each request fails with a 401 and then it gives up. > In order to resolve the issue, I must create a temporary url because that > responds to the 401 and creates a new token - which is then stored by > jclouds. I can then upload new blobs until that token has expired (after an > hour) > Output and the script itself can be found here: > https://gist.github.com/alexcouper/b8ca68a58a4f39b5e0dc > It should be noted that when running this script I have altered [token] > expiration in /etc/keystone/keystone.conf to be 2 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCLOUDS-1179) putBlob doesn't handle 401s
Nick Howes created JCLOUDS-1179: --- Summary: putBlob doesn't handle 401s Key: JCLOUDS-1179 URL: https://issues.apache.org/jira/browse/JCLOUDS-1179 Project: jclouds Issue Type: Bug Components: jclouds-blobstore Affects Versions: 1.7.1 Environment: Keystone + Swift on OpenStack Havana Ubuntu 12.04 Reporter: Nick Howes After the token used by jclouds expires, subsequent `putBlob` requests to swift fail with 401. Unlike creations of temporary urls, the `putBlob` command does not resolve this by `POST`ing to keystone, but instead tries a few times to `PUT` the blob to swift. Each request fails with a 401 and then it gives up. In order to resolve the issue, I must create a temporary url because that responds to the 401 and creates a new token - which is then stored by jclouds. I can then upload new blobs until that token has expired (after an hour) Output and the script itself can be found here: https://gist.github.com/alexcouper/b8ca68a58a4f39b5e0dc It should be noted that when running this script I have altered [token] expiration in /etc/keystone/keystone.conf to be 2 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCLOUDS-1179) putBlob doesn't handle 401s
[ https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Howes updated JCLOUDS-1179: Description: After the token used by jclouds expires, subsequent `putBlob` requests to swift fail with 401. Unlike other operations, the `putBlob` command does not resolve this by `POST`ing to keystone, but instead tries a few times to `PUT` the blob to swift. Each request fails with a 401 and then it gives up. Other operations such as a get _will_ handle a retry by refreshing the auth token, after which subsequent puts work (until the next expiry) Project to reproduce can be found here https://github.com/UniversityofWarwick/jclouds-bug It should be noted that when running this script I have altered [token] expiration in /etc/keystone/keystone.conf to be 2 seconds. was: After the token used by jclouds expires, subsequent `putBlob` requests to swift fail with 401. Unlike creations of temporary urls, the `putBlob` command does not resolve this by `POST`ing to keystone, but instead tries a few times to `PUT` the blob to swift. Each request fails with a 401 and then it gives up. In order to resolve the issue, I must create a temporary url because that responds to the 401 and creates a new token - which is then stored by jclouds. I can then upload new blobs until that token has expired (after an hour) Output and the script itself can be found here: https://gist.github.com/alexcouper/b8ca68a58a4f39b5e0dc It should be noted that when running this script I have altered [token] expiration in /etc/keystone/keystone.conf to be 2 seconds. > putBlob doesn't handle 401s > > > Key: JCLOUDS-1179 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1179 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.7.1, 2.0.0 > Environment: Keystone + Swift on OpenStack Havana > Ubuntu 12.04 >Reporter: Nick Howes > Labels: swift > > After the token used by jclouds expires, subsequent `putBlob` requests to > swift fail with 401. > Unlike other operations, the `putBlob` command does not resolve this by > `POST`ing to keystone, but instead tries a few times to `PUT` the blob to > swift. Each request fails with a 401 and then it gives up. > Other operations such as a get _will_ handle a retry by refreshing the auth > token, after which subsequent puts work (until the next expiry) > Project to reproduce can be found here > https://github.com/UniversityofWarwick/jclouds-bug > It should be noted that when running this script I have altered [token] > expiration in /etc/keystone/keystone.conf to be 2 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCLOUDS-1179) putBlob doesn't handle 401s
[ https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Howes updated JCLOUDS-1179: Environment: Devstack on Ubuntu 14.04 (was: Keystone + Swift on OpenStack Havana Ubuntu 12.04) > putBlob doesn't handle 401s > > > Key: JCLOUDS-1179 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1179 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.7.1, 2.0.0 > Environment: Devstack on Ubuntu 14.04 >Reporter: Nick Howes > Labels: swift > > After the token used by jclouds expires, subsequent `putBlob` requests to > swift fail with 401. > Unlike other operations, the `putBlob` command does not resolve this by > `POST`ing to keystone, but instead tries a few times to `PUT` the blob to > swift. Each request fails with a 401 and then it gives up. > Other operations such as a get _will_ handle a retry by refreshing the auth > token, after which subsequent puts work (until the next expiry) > Project to reproduce can be found here > https://github.com/UniversityofWarwick/jclouds-bug > It should be noted that when running this script I have altered [token] > expiration in /etc/keystone/keystone.conf to be 2 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (JCLOUDS-1179) putBlob doesn't handle 401s
[
https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15493137#comment-15493137
]
Nick Howes edited comment on JCLOUDS-1179 at 9/15/16 12:14 PM:
---
Cloned from original issue relating to the old {{swift}} provider - this bug
relates to {{2.0.0-SNAPSHOT}} where the problem can still be found in the
{{openstack-swift}} provider.
was (Author: nhowes):
Cloned from original issue relating to the old {{swift}} provider - this bug
relates to {{2.0.0-SNAPSHOT}} where the problem can still be found.
> putBlob doesn't handle 401s
>
>
> Key: JCLOUDS-1179
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1179
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.7.1, 2.0.0
> Environment: Devstack on Ubuntu 14.04
>Reporter: Nick Howes
> Labels: openstack-swift, swift
>
> After the token used by jclouds expires, subsequent `putBlob` requests to
> swift fail with 401.
> Unlike other operations, the `putBlob` command does not resolve this by
> `POST`ing to keystone, but instead tries a few times to `PUT` the blob to
> swift. Each request fails with a 401 and then it gives up.
> Other operations such as a get _will_ handle a retry by refreshing the auth
> token, after which subsequent puts work (until the next expiry)
> Project to reproduce can be found here
> https://github.com/UniversityofWarwick/jclouds-bug
> It should be noted that when running this script I have altered [token]
> expiration in /etc/keystone/keystone.conf to be 2 seconds.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1179) putBlob doesn't handle 401s
[
https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15493137#comment-15493137
]
Nick Howes commented on JCLOUDS-1179:
-
Cloned from original issue relating to the old {{swift}} provider - this bug
relates to {{2.0.0-SNAPSHOT}} where the problem can still be found.
> putBlob doesn't handle 401s
>
>
> Key: JCLOUDS-1179
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1179
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.7.1, 2.0.0
> Environment: Devstack on Ubuntu 14.04
>Reporter: Nick Howes
> Labels: openstack-swift, swift
>
> After the token used by jclouds expires, subsequent `putBlob` requests to
> swift fail with 401.
> Unlike other operations, the `putBlob` command does not resolve this by
> `POST`ing to keystone, but instead tries a few times to `PUT` the blob to
> swift. Each request fails with a 401 and then it gives up.
> Other operations such as a get _will_ handle a retry by refreshing the auth
> token, after which subsequent puts work (until the next expiry)
> Project to reproduce can be found here
> https://github.com/UniversityofWarwick/jclouds-bug
> It should be noted that when running this script I have altered [token]
> expiration in /etc/keystone/keystone.conf to be 2 seconds.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCLOUDS-1179) putBlob doesn't handle 401s
[ https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Howes updated JCLOUDS-1179: Labels: openstack-swift swift (was: swift) > putBlob doesn't handle 401s > > > Key: JCLOUDS-1179 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1179 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.7.1, 2.0.0 > Environment: Devstack on Ubuntu 14.04 >Reporter: Nick Howes > Labels: openstack-swift, swift > > After the token used by jclouds expires, subsequent `putBlob` requests to > swift fail with 401. > Unlike other operations, the `putBlob` command does not resolve this by > `POST`ing to keystone, but instead tries a few times to `PUT` the blob to > swift. Each request fails with a 401 and then it gives up. > Other operations such as a get _will_ handle a retry by refreshing the auth > token, after which subsequent puts work (until the next expiry) > Project to reproduce can be found here > https://github.com/UniversityofWarwick/jclouds-bug > It should be noted that when running this script I have altered [token] > expiration in /etc/keystone/keystone.conf to be 2 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCLOUDS-1179) putBlob doesn't handle 401s
[ https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Howes updated JCLOUDS-1179: Affects Version/s: (was: 1.7.1) 1.9.2 > putBlob doesn't handle 401s > > > Key: JCLOUDS-1179 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1179 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.9.2, 2.0.0 > Environment: Devstack on Ubuntu 14.04 >Reporter: Nick Howes > Labels: openstack-swift, swift > > After the token used by jclouds expires, subsequent `putBlob` requests to > swift fail with 401. > Unlike other operations, the `putBlob` command does not resolve this by > `POST`ing to keystone, but instead tries a few times to `PUT` the blob to > swift. Each request fails with a 401 and then it gives up. > Other operations such as a get _will_ handle a retry by refreshing the auth > token, after which subsequent puts work (until the next expiry) > Project to reproduce can be found here > https://github.com/UniversityofWarwick/jclouds-bug > It should be noted that when running this script I have altered [token] > expiration in /etc/keystone/keystone.conf to be 2 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1179) putBlob doesn't handle 401s
[
https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15493158#comment-15493158
]
Nick Howes commented on JCLOUDS-1179:
-
Reproduced using Devstack with Swift enabled, and 2-second expiration with this
in {{local.sh}}
{code}
sudo sed -i -e "s/^#*expiration *=.*/expiration = 2/"
/etc/keystone/keystone.conf
{code}
> putBlob doesn't handle 401s
>
>
> Key: JCLOUDS-1179
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1179
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.9.2, 2.0.0
> Environment: Devstack on Ubuntu 14.04
>Reporter: Nick Howes
> Labels: openstack-swift, swift
>
> After the token used by jclouds expires, subsequent `putBlob` requests to
> swift fail with 401.
> Unlike other operations, the `putBlob` command does not resolve this by
> `POST`ing to keystone, but instead tries a few times to `PUT` the blob to
> swift. Each request fails with a 401 and then it gives up.
> Other operations such as a get _will_ handle a retry by refreshing the auth
> token, after which subsequent puts work (until the next expiry)
> Project to reproduce can be found here
> https://github.com/UniversityofWarwick/jclouds-bug
> It should be noted that when running this script I have altered [token]
> expiration in /etc/keystone/keystone.conf to be 2 seconds.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1179) putBlob doesn't handle 401s
[
https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15493209#comment-15493209
]
Nick Howes commented on JCLOUDS-1179:
-
On a blobStore.getBlob, when BaseHttpCommandExecutorService encounters a 401 it
is returned as a normal response and so handled by the client retry handler,
which is RetryOnRenew which renews tokens. On a blobStore.putBlob, a
ProtocolException is thrown and it is handled by the IOExceptionRetryHandler,
which is BackoffLimitedRetryHandler which retries 5 times but doesn't renew
tokens.
This seems to be because of HttpUrlConnection (the Sun/Oracle implementation
anyway), which will throw {{ProtocolException("Server rejected operation")}} if
the request has {{Expect: 100-Continue}} header but it receives anything other
than a 100.
> putBlob doesn't handle 401s
>
>
> Key: JCLOUDS-1179
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1179
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.9.2, 2.0.0
> Environment: Devstack on Ubuntu 14.04
>Reporter: Nick Howes
> Labels: openstack-swift, swift
>
> After the token used by jclouds expires, subsequent `putBlob` requests to
> swift fail with 401.
> Unlike other operations, the `putBlob` command does not resolve this by
> `POST`ing to keystone, but instead tries a few times to `PUT` the blob to
> swift. Each request fails with a 401 and then it gives up.
> Other operations such as a get _will_ handle a retry by refreshing the auth
> token, after which subsequent puts work (until the next expiry)
> Project to reproduce can be found here
> https://github.com/UniversityofWarwick/jclouds-bug
> It should be noted that when running this script I have altered [token]
> expiration in /etc/keystone/keystone.conf to be 2 seconds.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [jclouds/jclouds-labs] Pb compute api (#292)
@alibazlamit pushed 1 commit. 3e79df9 pb-compute-api -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/jclouds/jclouds-labs/pull/292/files/b5805fcfebc1593117510dde5134a8482afb8d4c..3e79df9c8d1d358fa8d4b6b11e59b587213d6099
[jira] [Comment Edited] (JCLOUDS-1179) putBlob doesn't handle 401s
[
https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15493209#comment-15493209
]
Nick Howes edited comment on JCLOUDS-1179 at 9/15/16 12:58 PM:
---
On a blobStore.getBlob, when BaseHttpCommandExecutorService encounters a 401 it
is returned as a normal response and so handled by the client retry handler,
which is RetryOnRenew which renews tokens. On a blobStore.putBlob, a
ProtocolException is thrown and it is handled by the IOExceptionRetryHandler,
which is BackoffLimitedRetryHandler which retries 5 times but doesn't renew
tokens.
This seems to be because of HttpUrlConnection (the Sun/Oracle implementation
anyway), which will throw {{ProtocolException("Server rejected operation")}} if
the request has {{Expect: 100-Continue}} header but it receives anything other
than a 100. Hence the different behaviour compared to any other non-Expecting
request.
https://github.com/openjdk-mirror/jdk/blob/jdk8u/jdk8u/master/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L1215
was (Author: nhowes):
On a blobStore.getBlob, when BaseHttpCommandExecutorService encounters a 401 it
is returned as a normal response and so handled by the client retry handler,
which is RetryOnRenew which renews tokens. On a blobStore.putBlob, a
ProtocolException is thrown and it is handled by the IOExceptionRetryHandler,
which is BackoffLimitedRetryHandler which retries 5 times but doesn't renew
tokens.
This seems to be because of HttpUrlConnection (the Sun/Oracle implementation
anyway), which will throw {{ProtocolException("Server rejected operation")}} if
the request has {{Expect: 100-Continue}} header but it receives anything other
than a 100.
> putBlob doesn't handle 401s
>
>
> Key: JCLOUDS-1179
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1179
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.9.2, 2.0.0
> Environment: Devstack on Ubuntu 14.04
>Reporter: Nick Howes
> Labels: openstack-swift, swift
>
> After the token used by jclouds expires, subsequent `putBlob` requests to
> swift fail with 401.
> Unlike other operations, the `putBlob` command does not resolve this by
> `POST`ing to keystone, but instead tries a few times to `PUT` the blob to
> swift. Each request fails with a 401 and then it gives up.
> Other operations such as a get _will_ handle a retry by refreshing the auth
> token, after which subsequent puts work (until the next expiry)
> Project to reproduce can be found here
> https://github.com/UniversityofWarwick/jclouds-bug
> It should be noted that when running this script I have altered [token]
> expiration in /etc/keystone/keystone.conf to be 2 seconds.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [jclouds/jclouds-labs] Pb compute api (#292)
@alibazlamit pushed 1 commit. 61bee69 pb-compute-api -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/jclouds/jclouds-labs/pull/292/files/db0fb685f13c614e3ad02f0032fe85ac286ef848..61bee693c3361a42764f3480798f9606bd89ac7c
Re: [jclouds/jclouds-labs] Pb compute api (#292)
@devcsrj the support for arbitrary CPU, RAM and Storage was done something was not right with the branch i pushed, now i have updated it to the upstream and squashed all the changes in one commit, one issue i noticed is that its diffing white spaces and eol, i have configure eol to be lf but still its showing me a lot of changes maybe @nacx can help too on this one. Other than the diff issue the branch is ready for reviewing. Thanks -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/292#issuecomment-247327921
[jira] [Created] (JCLOUDS-1180) No SNI support with default Java and Apache HTTPS client
Klemen created JCLOUDS-1180: --- Summary: No SNI support with default Java and Apache HTTPS client Key: JCLOUDS-1180 URL: https://issues.apache.org/jira/browse/JCLOUDS-1180 Project: jclouds Issue Type: Bug Components: jclouds-drivers Affects Versions: 2.0.0 Reporter: Klemen Priority: Minor SNI is a TLS extension that basically tells which hostname it wants certificate for before handshake. Simple setup would be a reverse proxy serving 2 different subdomains each one with it's own certificate while having a single static IP. Popular setup, especially with let's encrypt nowadays. The bug was triggered after trying to connect to a FakeS3 server behind a reverse proxy described above. JClouds throws an SSL error telling that PKIX path is wrong even though it's actually not. SNI support works fine with OkHttp driver. My best guess so far as the possible reasons are: 1. For default Java client an OpenJDK bug which may or may not have a workaround: http://stackoverflow.com/questions/30817934/extended-server-name-sni-extension-not-sent-with-jdk1-8-0-but-send-with-jdk1-7 2. For Apache client: https://issues.jboss.org/browse/KEYCLOAK-2439 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCLOUDS-1179) putBlob doesn't handle 401s
[ https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Gaul updated JCLOUDS-1179: - Labels: openstack-swift (was: openstack-swift swift) > putBlob doesn't handle 401s > > > Key: JCLOUDS-1179 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1179 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.9.2, 2.0.0 > Environment: Devstack on Ubuntu 14.04 >Reporter: Nick Howes > Labels: openstack-swift > > After the token used by jclouds expires, subsequent `putBlob` requests to > swift fail with 401. > Unlike other operations, the `putBlob` command does not resolve this by > `POST`ing to keystone, but instead tries a few times to `PUT` the blob to > swift. Each request fails with a 401 and then it gives up. > Other operations such as a get _will_ handle a retry by refreshing the auth > token, after which subsequent puts work (until the next expiry) > Project to reproduce can be found here > https://github.com/UniversityofWarwick/jclouds-bug > It should be noted that when running this script I have altered [token] > expiration in /etc/keystone/keystone.conf to be 2 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCLOUDS-1179) putBlob doesn't handle 401s
[ https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Gaul updated JCLOUDS-1179: - Assignee: Zack Shoylev > putBlob doesn't handle 401s > > > Key: JCLOUDS-1179 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1179 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.9.2, 2.0.0 > Environment: Devstack on Ubuntu 14.04 >Reporter: Nick Howes >Assignee: Zack Shoylev > Labels: openstack-swift > > After the token used by jclouds expires, subsequent `putBlob` requests to > swift fail with 401. > Unlike other operations, the `putBlob` command does not resolve this by > `POST`ing to keystone, but instead tries a few times to `PUT` the blob to > swift. Each request fails with a 401 and then it gives up. > Other operations such as a get _will_ handle a retry by refreshing the auth > token, after which subsequent puts work (until the next expiry) > Project to reproduce can be found here > https://github.com/UniversityofWarwick/jclouds-bug > It should be noted that when running this script I have altered [token] > expiration in /etc/keystone/keystone.conf to be 2 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1179) putBlob doesn't handle 401s
[ https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15494139#comment-15494139 ] Andrew Gaul commented on JCLOUDS-1179: -- [~zack-s] Can you investigate this? > putBlob doesn't handle 401s > > > Key: JCLOUDS-1179 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1179 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.9.2, 2.0.0 > Environment: Devstack on Ubuntu 14.04 >Reporter: Nick Howes >Assignee: Zack Shoylev > Labels: openstack-swift > > After the token used by jclouds expires, subsequent `putBlob` requests to > swift fail with 401. > Unlike other operations, the `putBlob` command does not resolve this by > `POST`ing to keystone, but instead tries a few times to `PUT` the blob to > swift. Each request fails with a 401 and then it gives up. > Other operations such as a get _will_ handle a retry by refreshing the auth > token, after which subsequent puts work (until the next expiry) > Project to reproduce can be found here > https://github.com/UniversityofWarwick/jclouds-bug > It should be noted that when running this script I have altered [token] > expiration in /etc/keystone/keystone.conf to be 2 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1176) Swift delete operation is not idempotent
[
https://issues.apache.org/jira/browse/JCLOUDS-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15494392#comment-15494392
]
Zack Shoylev commented on JCLOUDS-1176:
---
I am noticing that we already have a deleteObjectNotFound integration test in
blobstore?
> Swift delete operation is not idempotent
>
>
> Key: JCLOUDS-1176
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1176
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.9.0, 1.9.1, 1.9.2
>Reporter: Vijay Panghal
>Assignee: Zack Shoylev
> Labels: openstack-swift
>
> Openstack Swift delete operation used to be idempotent. But after this pull
> request https://github.com/jclouds/jclouds/pull/700
> second delete is failing with these stack trace
> {quote}
> org.jclouds.http.HttpResponseException: java.io.IOException: stream is closed
> connecting to DELETE
> https://dal05.objectstorage.softlayer.net/v1/AUTH_0eb7ef10-6761-4384-ab47-9187592f30b1/cloud-testing/74f346838a7b550f
> HTTP/1.1
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:114)
> at
> org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:90)
> at
> org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:73)
> at
> org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:44)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156)
> at
> org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123)
> at com.sun.proxy.$Proxy67.removeObject(Unknown Source)
> at
> org.jclouds.openstack.swift.blobstore.SwiftBlobStore.removeBlob(SwiftBlobStore.java:260)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:37)
> at com.sun.proxy.$Proxy69.removeBlob(Unknown Source)
> at
> com.maginatics.raptor.data.BlobStoreTest.testBlobRemoveIdempotence(BlobStoreTest.java:208)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393)
> at
> org.apache.maven.surefire.junitcore.pc.InvokerStrategy.schedule(InvokerStrategy.java:54)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:352)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.con
[jira] [Commented] (JCLOUDS-1179) putBlob doesn't handle 401s
[ https://issues.apache.org/jira/browse/JCLOUDS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15494526#comment-15494526 ] Zack Shoylev commented on JCLOUDS-1179: --- Ah, nice catch. I'll look into it. > putBlob doesn't handle 401s > > > Key: JCLOUDS-1179 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1179 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 1.9.2, 2.0.0 > Environment: Devstack on Ubuntu 14.04 >Reporter: Nick Howes >Assignee: Zack Shoylev > Labels: openstack-swift > > After the token used by jclouds expires, subsequent `putBlob` requests to > swift fail with 401. > Unlike other operations, the `putBlob` command does not resolve this by > `POST`ing to keystone, but instead tries a few times to `PUT` the blob to > swift. Each request fails with a 401 and then it gives up. > Other operations such as a get _will_ handle a retry by refreshing the auth > token, after which subsequent puts work (until the next expiry) > Project to reproduce can be found here > https://github.com/UniversityofWarwick/jclouds-bug > It should be noted that when running this script I have altered [token] > expiration in /etc/keystone/keystone.conf to be 2 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jclouds/jclouds-labs] Pb compute api (#292)
Now that's a **LOT** of formatting noise, even GitHub couldn't render. :(  Assuming you used the IDE formatting profiles, then the formatting noise is most probably caused by earlier PB-related PRs not formatted properly. i.e.: Braces on single-line ifs:  ..or untrimmed whitespaces:  Here's what I suggest, to move this PR into a reviewable state: - Rebase this branch to `master` - Re-apply **ONLY** the compute-api related changes, using the correct formatting Don't reformat the rest of the codebase _yet_; only the once you've changed. After this gets merged, we'll dedicated a separate PR for the sole purpose of reformatting the rest of the codebase. That way we keep the changes to it's own PRs, making the review possible. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/292#issuecomment-247495155
