[jira] [Commented] (JCLOUDS-793) make blobstore put operations report server errors via HttpResponseException
[
https://issues.apache.org/jira/browse/JCLOUDS-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14242005#comment-14242005
]
Jeremy Daggett commented on JCLOUDS-793:
Thanks [~dchsueh], if you could share any snippets of the exceptions from the
logs, that would be great.
> make blobstore put operations report server errors via HttpResponseException
>
>
> Key: JCLOUDS-793
> URL: https://issues.apache.org/jira/browse/JCLOUDS-793
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-blobstore
>Affects Versions: 1.8.1
>Reporter: Daniel Hsueh
>Assignee: Jeremy Daggett
> Labels: features
>
> observed with openstack-swift 1.8.1 ObjectApi.put()
> if the server responds with a 4xx/5xx response, the put() call returns null
> for the etag
> would it be more useful if there was an HttpResponseException were thrown,
> with the actual request, response, and response code available? as of now,
> the null response only indicates that an etag was not found in the response,
> not that the whole request failed
> I observe that a failure to communicate (e.g. BackoffLimitedRetryHandler
> running through its retires) will result in an HttpResponseException
> there may also be an issue with consistency -- from perusing the
> AzureBlobClient and S3Client code it seems like an HttpException("did not
> receive ETag") would be thrown, and not a null etag
> I would also propose that GETs report 4xx/5xx responses via
> HttpResponseException as well
> I realize this is a major departure from existing behavior, perhaps this
> exception-reporting-on-error could be enabled via an override?
> thank you
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (JCLOUDS-793) make blobstore put operations report server errors via HttpResponseException
[
https://issues.apache.org/jira/browse/JCLOUDS-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Daggett reassigned JCLOUDS-793:
--
Assignee: Jeremy Daggett
> make blobstore put operations report server errors via HttpResponseException
>
>
> Key: JCLOUDS-793
> URL: https://issues.apache.org/jira/browse/JCLOUDS-793
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-blobstore
>Affects Versions: 1.8.1
>Reporter: Daniel Hsueh
>Assignee: Jeremy Daggett
> Labels: features
>
> observed with openstack-swift 1.8.1 ObjectApi.put()
> if the server responds with a 4xx/5xx response, the put() call returns null
> for the etag
> would it be more useful if there was an HttpResponseException were thrown,
> with the actual request, response, and response code available? as of now,
> the null response only indicates that an etag was not found in the response,
> not that the whole request failed
> I observe that a failure to communicate (e.g. BackoffLimitedRetryHandler
> running through its retires) will result in an HttpResponseException
> there may also be an issue with consistency -- from perusing the
> AzureBlobClient and S3Client code it seems like an HttpException("did not
> receive ETag") would be thrown, and not a null etag
> I would also propose that GETs report 4xx/5xx responses via
> HttpResponseException as well
> I realize this is a major departure from existing behavior, perhaps this
> exception-reporting-on-error could be enabled via an override?
> thank you
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [jclouds] Fixed Version in FormSignerV4 (#625)
Had running IDEA in power-save mode and missed that. Removed them. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/625#issuecomment-66539285
Re: [jclouds] Fixed Version in FormSignerV4 (#625)
The build failed due to [three new check style violations](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/1458/org.apache.jclouds.api$sts/violations/file/src/main/java/org/jclouds/aws/filters/FormSignerV4.java/). Those are just unused imports left there after removing the unused private method. Mind removing those imports? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/625#issuecomment-66530286
Re: [jclouds-labs-google] added CreationTimestamp to HttpHealthCheck and TargetPool + refactor War... (#111)
Addressed comments and squashed. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/111#issuecomment-66530436
Re: [jclouds-labs-google] added CreationTimestamp to HttpHealthCheck and TargetPool + refactor War... (#111)
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +package org.jclouds.googlecomputeengine.domain;
> +
> +import org.jclouds.json.SerializedNames;
> +
> +import com.google.auto.value.AutoValue;
> +
> +@AutoValue
> +public abstract class KeyValuePair {
> +
> + abstract String key();
> +
> + abstract String value();
Nice catch, the properties were package-private from when they were declared in
the Metadata class which has implemented get functions. They are now used in
the Warning class as well so they should be public.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-google/pull/111/files#r21640441
Re: [jclouds-labs-google] added CreationTimestamp to HttpHealthCheck and TargetPool + refactor War... (#111)
Just a couple minors. Changes lgtm. Thanks! --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/111#issuecomment-66528998
Re: [jclouds-labs-google] added CreationTimestamp to HttpHealthCheck and TargetPool + refactor War... (#111)
> + AccessConfig config = AccessConfig.create("test-config",
> Type.ONE_TO_ONE_NAT, null);
> +
> assertOperationDoneSuccessfully(api().addAccessConfigToNic(INSTANCE_NAME,
> config, "nic0"));
> + Instance instance = api().get(INSTANCE_NAME);
> + assertNotNull(instance);
> +
> assertEquals(instance.networkInterfaces().get(0).accessConfigs().get(0).name(),
> "test-config");
> + }
> +
> + @Test(groups = "live", dependsOnMethods = "testAddAccessConfig")
> + public void testDeleteAccessConfig() {
> + Instance instance = api().get(INSTANCE_NAME);
> + System.out.println(instance);
> +
> assertOperationDoneSuccessfully(api().deleteAccessConfigFromNic(INSTANCE_NAME,
> "test-config", "nic0"));
> + instance = api().get(INSTANCE_NAME);
> + assertNotNull(instance);
> +
> assertTrue(instance.networkInterfaces().get(0).accessConfigs().isEmpty());
> + }
Remove the System.out and properly indent the closing `}`.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-google/pull/111/files#r21639764
Re: [jclouds-labs-google] added CreationTimestamp to HttpHealthCheck and TargetPool + refactor War... (#111)
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +package org.jclouds.googlecomputeengine.domain;
> +
> +import org.jclouds.json.SerializedNames;
> +
> +import com.google.auto.value.AutoValue;
> +
> +@AutoValue
> +public abstract class KeyValuePair {
> +
> + abstract String key();
> +
> + abstract String value();
Are these properties *package-private* for any particular reason? In that case,
would it make sense to make the whole class package-private? (I'm not sure if
that will prevent it from being deserialised properly):
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-google/pull/111/files#r21639540
[jira] [Closed] (JCLOUDS-86) fgcp: two compute live tests intermittently fail to ssh in, testConcurrentUseOfComputeServiceToCreateNodes and testAScriptExecutionAfterBootWithBasicTemplate
[
https://issues.apache.org/jira/browse/JCLOUDS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignasi Barrera closed JCLOUDS-86.
-
Resolution: Won't Fix
The FGCP provider has been removed.
> fgcp: two compute live tests intermittently fail to ssh in,
> testConcurrentUseOfComputeServiceToCreateNodes and
> testAScriptExecutionAfterBootWithBasicTemplate
> -
>
> Key: JCLOUDS-86
> URL: https://issues.apache.org/jira/browse/JCLOUDS-86
> Project: jclouds
> Issue Type: Task
>Reporter: Dies Koper
>
> gaul suggested on irc that I open a JIRA with remaining tasks for fgcp:
> 1. Intermittent test failure
> 2. Clean up apis (few WIP comments, WPI methods)
> 3. Add more apis
> 1. When I run the live tests, I usually get: Tests run: 113, Failures: 1,
> Errors: 0, Skipped: 0
> The failure is sometimes in testConcurrentUseOfComputeServiceToCreateNodes ,
> sometimes in testAScriptExecutionAfterBootWithBasicTemplate, with the same
> error:
> java.util.NoSuchElementException: could not connect to any ip address port 22
> on node {id=UZXC0GRT-ZG8ZJCJ07-S-0529, providerId=UZXC0GRT-ZG8ZJCJ07-S-0529,
> name=
> twin1-fe1, location={scope=NETWORK, id=UZXC0GRT-ZG8ZJCJ07-N-DMZ,
> description=DMZ, parent=UZXC0GRT-ZG8ZJCJ07}, group=twin1,
> imageId=IMG_I7BXIFH6T3TRZ5BOPNF3, os=
> {family=centos, name=CentOS 6.2 64bit (English), arch=pv, version=6.2,
> description=CentOS 6.2 64bit (English), is64Bit=true}, status=RUNNING,
> loginPort=22, privateAddresses=[192.168.0.12], hardware={id=islanda-cbrm_140,
> providerId=islanda-cbrm_140, name=economy, processors=[{cores=1.0,
> speed=1.0}], ram=1700, supportsImage=is64Bit()}, loginUser=root}
> at
> org.jclouds.compute.util.ConcurrentOpenSocketFinder.findOpenSocketOnNode(ConcurrentOpenSocketFinder.java:106)
> at
> org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.call(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:132)
> ...
> When I run them by themselves (i.e. disable all other tests (except
> dependency testCompareSizes of course)), they both pass. When I run them in
> the Eclipse debugger, they pass.
> I believe the ssh timeout is 300 sec, more than enough.
> 2. API cleanup:
> - VirtualDCApi has some commented out annotations from when I was
> experimenting with jaxb vs sax
> - BuiltinServerApi and FirewallApi/LoadBalancerApi (and corresponding domain
> classes), I was looking at moving FW and SLB specific methods to their own
> specific classes and improve method names, usability.
> 3. FGCP API has more APIs which we could add.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-104) Change labs/cli/karaf to have their own parent POMs separate from the top-level POM
[
https://issues.apache.org/jira/browse/JCLOUDS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14241725#comment-14241725
]
Ignasi Barrera commented on JCLOUDS-104:
Having a look at the repos:
* jclouds-chef repo is deprecated, so nothing to do there.
* jclouds-cli is OK.
* jclouds-karaf uses its own parent pom and is not using the aggregate javadocs
plugin, so shouldn't present issues when releasing with Maven.
* jclouds-labs needs to be changed.
* jclouds-labs-aws has some projects OK and some that have to be changed.
* jclouds-labs-google has to be changed too.
The changes to be applied to the remaining repos are:
* Change each individual project in the repo, and the root pom.xml to use
{{jclouds-project}} as a parent.
* Replace all occurrences of {{jclouds.version}} by {{project.parent.version}}.
The jclouds-labs-openstack repo can be used as a model to apply the changes.
As [~abayer] says, the issue is having projects depending on the "aggregator"
pom.xml (the root pom.xml in the repo). As the parent pom gets build first, if
it "does stuff" such as generating the aggregate javadocs, weird things will
happen, as that will run *before* the build of the child repos is done.
> Change labs/cli/karaf to have their own parent POMs separate from the
> top-level POM
> ---
>
> Key: JCLOUDS-104
> URL: https://issues.apache.org/jira/browse/JCLOUDS-104
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-cli, jclouds-karaf, jclouds-labs,
> jclouds-labs-aws, jclouds-labs-google, jclouds-labs-openstack
>Reporter: Andrew Bayer
>Assignee: Zack Shoylev
> Attachments: JCLOUDS-104-cli.patch
>
>
> Currently, jclouds and jclouds-chef each have a parent POM,
> (repo)/project/pom.xml, which all the other POMs, including the top-level
> POM, in the project inherit from. jclouds-labs*, jclouds-cli and
> jclouds-karaf all just have the top-level POM, and everything else inherits
> from that top-level POM. That makes some processes (like aggregate javadoc
> and assemblies) done in the top-level POM a bit problematic for the first
> build of a new version (i.e., in releases). It'd be nice if these projects
> separated out the parent and top-level POM functionality as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JCLOUDS-632) L7 Load Balancing
[ https://issues.apache.org/jira/browse/JCLOUDS-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera resolved JCLOUDS-632. Resolution: Fixed Fix Version/s: 1.9.0 2.0.0 > L7 Load Balancing > - > > Key: JCLOUDS-632 > URL: https://issues.apache.org/jira/browse/JCLOUDS-632 > Project: jclouds > Issue Type: New Feature > Components: jclouds-labs-google >Reporter: Ashlie Martinez >Priority: Minor > Fix For: 2.0.0, 1.9.0 > > > Add support for L7 load balancing by introducing support for Global > Forwarding Rules, Target Http Proxies, Url Maps, Backend Resources, and > Resource Views -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-141) Create super-parent POM that jclouds and other components inherit from
[ https://issues.apache.org/jira/browse/JCLOUDS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14241680#comment-14241680 ] Ignasi Barrera commented on JCLOUDS-141: If I'm not wrong, jclouds-project is used by all repos as the parent pom, since 1.8, right? It's just to put the right fix version when marking the issue as resolved. > Create super-parent POM that jclouds and other components inherit from > -- > > Key: JCLOUDS-141 > URL: https://issues.apache.org/jira/browse/JCLOUDS-141 > Project: jclouds > Issue Type: Task > Components: jclouds-chef, jclouds-cli, jclouds-core, jclouds-karaf, > jclouds-labs, jclouds-labs-aws, jclouds-labs-google, jclouds-labs-openstack >Affects Versions: 1.6.1 >Reporter: Andrew Bayer >Assignee: Andrew Bayer > > Now that we release all the components at once, it'd make sense to have one > common super-parent POM they all inherited from, where we can define the > version (so we don't have to update properties in chef/cli/karaf/etc when > jclouds' version changes, etc) and the like. It'd make releasing simpler. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jclouds] Fixed Version in FormSignerV4 (#625)
Thanks! I'll merge it once the PR builders say they're happy :) Regarding the branch, I have to say that it is unlikely that a new version of the 1.7 series is released (snapshots are published as soon as patches are merged, though). I'll cherry-pick this patch to 1.8.x and master too. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/625#issuecomment-66518201
[jclouds-labs-google] New MockTests: TargetHttpProxyApi, UrlMap, ZoneApi, FirewallApi (#113)
You can merge this Pull Request by running: git pull https://github.com/GoogleCloudPlatform/jclouds-labs-google toMockPartIII Or you can view, comment on it, or merge it online at: https://github.com/jclouds/jclouds-labs-google/pull/113 -- Commit Summary -- * New MockTests: TargetHttpProxyApi, UrlMap, ZoneApi, FirewallApi -- File Changes -- M google-compute-engine/src/test/java/org/jclouds/googlecomputeengine/features/FirewallApiExpectTest.java (122) M google-compute-engine/src/test/java/org/jclouds/googlecomputeengine/features/FirewallApiMockTest.java (40) D google-compute-engine/src/test/java/org/jclouds/googlecomputeengine/features/TargetHttpProxyApiExpectTest.java (171) A google-compute-engine/src/test/java/org/jclouds/googlecomputeengine/features/TargetHttpProxyApiMockTest.java (99) M google-compute-engine/src/test/java/org/jclouds/googlecomputeengine/features/UrlMapApiExpectTest.java (159) A google-compute-engine/src/test/java/org/jclouds/googlecomputeengine/features/UrlMapApiMockTest.java (140) D google-compute-engine/src/test/java/org/jclouds/googlecomputeengine/features/ZoneApiExpectTest.java (95) A google-compute-engine/src/test/java/org/jclouds/googlecomputeengine/features/ZoneApiMockTest.java (63) M google-compute-engine/src/test/java/org/jclouds/googlecomputeengine/parse/ParseTargetHttpProxyListTest.java (15) M google-compute-engine/src/test/java/org/jclouds/googlecomputeengine/parse/ParseTargetHttpProxyTest.java (12) M google-compute-engine/src/test/java/org/jclouds/googlecomputeengine/parse/ParseUrlMapListTest.java (13) M google-compute-engine/src/test/java/org/jclouds/googlecomputeengine/parse/ParseUrlMapTest.java (9) M google-compute-engine/src/test/java/org/jclouds/googlecomputeengine/parse/ParseUrlMapValidateTest.java (9) M google-compute-engine/src/test/java/org/jclouds/googlecomputeengine/parse/ParseZoneListTest.java (9) M google-compute-engine/src/test/java/org/jclouds/googlecomputeengine/parse/ParseZoneTest.java (7) M google-compute-engine/src/test/resources/firewall_insert.json (23) -- Patch Links -- https://github.com/jclouds/jclouds-labs-google/pull/113.patch https://github.com/jclouds/jclouds-labs-google/pull/113.diff --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/113
Re: [jclouds] Fixed Version in FormSignerV4 (#625)
@nacx Thanks, fixed. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/625#issuecomment-66517425
Re: [jclouds] Fixed Version in FormSignerV4 (#625)
If the `addVersionIfNecessary` is not used I'd remove it too, having it there can only cause confusion. Apart from that, the changes lgtm. Thanks! --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/625#issuecomment-66516803
Re: [jclouds] Fixed Version in FormSignerV4 (#625)
> + HttpRequest request = HttpRequest.builder() //
> +.method("POST") //
> +.endpoint("https://iam.amazonaws.com/";) //
> +.addHeader("Host", "iam.amazonaws.com") //
> +.payload("Action=CoolVersionWordAction")
> +.build();
> +
> +
> request.getPayload().getContentMetadata().setContentType("application/x-www-form-urlencoded;
> charset=utf-8");
> +
> + FormSignerV4 filter = new FormSignerV4(apiVersion, accessAndSecretKey,
> timestamp, serviceAndRegion);
> +
> + HttpRequest filtered = filter.filter(request);
> +
> + assertEquals(filtered.getFirstHeaderOrNull("X-Amz-Date"),
> timestamp.get());
> +
> +
> assertThat(filtered.getPayload().getRawContent().toString().contains("&Version="));
Assert that the parameter has the expected value, just for completeness?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/625/files#r21633502
Re: [jclouds] JCLOUDS-480 support version 4 signatures for aws-ec2. (bbd5175)
That was fast :) Thanks! --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/commit/bbd5175c19ccb499f3e39ddd9d997c7b194bc601#commitcomment-8919396
[jira] [Commented] (JCLOUDS-793) make blobstore put operations report server errors via HttpResponseException
[
https://issues.apache.org/jira/browse/JCLOUDS-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14241648#comment-14241648
]
Daniel Hsueh commented on JCLOUDS-793:
--
503 responses seem to get an HttpResponseException
408 seems to result in a null etag return
> make blobstore put operations report server errors via HttpResponseException
>
>
> Key: JCLOUDS-793
> URL: https://issues.apache.org/jira/browse/JCLOUDS-793
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-blobstore
>Affects Versions: 1.8.1
>Reporter: Daniel Hsueh
> Labels: features
>
> observed with openstack-swift 1.8.1 ObjectApi.put()
> if the server responds with a 4xx/5xx response, the put() call returns null
> for the etag
> would it be more useful if there was an HttpResponseException were thrown,
> with the actual request, response, and response code available? as of now,
> the null response only indicates that an etag was not found in the response,
> not that the whole request failed
> I observe that a failure to communicate (e.g. BackoffLimitedRetryHandler
> running through its retires) will result in an HttpResponseException
> there may also be an issue with consistency -- from perusing the
> AzureBlobClient and S3Client code it seems like an HttpException("did not
> receive ETag") would be thrown, and not a null etag
> I would also propose that GETs report 4xx/5xx responses via
> HttpResponseException as well
> I realize this is a major departure from existing behavior, perhaps this
> exception-reporting-on-error could be enabled via an override?
> thank you
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [jclouds] JCLOUDS-480 support version 4 signatures for aws-ec2. (bbd5175)
@nacx yep https://github.com/jclouds/jclouds/pull/625 --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/commit/bbd5175c19ccb499f3e39ddd9d997c7b194bc601#commitcomment-8919317
[jclouds] Fixed Version in FormSignerV4 (#625)
You can merge this Pull Request by running: git pull https://github.com/chemikadze/jclouds 1.7.x Or you can view, comment on it, or merge it online at: https://github.com/jclouds/jclouds/pull/625 -- Commit Summary -- * Fixed Version in FormSignerV4 -- File Changes -- M apis/sts/src/main/java/org/jclouds/aws/filters/FormSignerV4.java (10) M apis/sts/src/test/java/org/jclouds/aws/filters/FormSignerV4Test.java (19) -- Patch Links -- https://github.com/jclouds/jclouds/pull/625.patch https://github.com/jclouds/jclouds/pull/625.diff --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/625
Re: [jclouds] JCLOUDS-480 support version 4 signatures for aws-ec2. (bbd5175)
Nice catch @chemikadze! Mind opening an issue in [JIRA](https://issues.apache.org/jira/browse/JCLOUDS)? And also, do you want to try opening a pull request with a fix, so the version parameter is properly matched int he request string? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/commit/bbd5175c19ccb499f3e39ddd9d997c7b194bc601#commitcomment-8919221
Re: [jclouds] JCLOUDS-480 support version 4 signatures for aws-ec2. (bbd5175)
Ah, bug is more funny. If request has string `Version` in it (tag name, tag value, etc), lines 128-130 decide that Version already present and version is not added. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/commit/bbd5175c19ccb499f3e39ddd9d997c7b194bc601#commitcomment-8918830
Re: [jclouds] JCLOUDS-480 support version 4 signatures for aws-ec2. (bbd5175)
This method not used anywhere, and it looks like this causes TagsApi to fail,
because Version is missing from request form:
```
o.j.h.i.JavaUrlHttpCommandExecutorService: Sending request -1118951214: POST
https://ec2.us-east-1.amazonaws.com/ HTTP/1.1
jclouds.wire: >>
"Action=CreateTags&Tag.1.Key=Name&Tag.1.Value=test-54886996e4b07f52e92c6416-54886996e4b0bc25677c9675&Tag.2.Key=owner_id&Tag.2.Value=522dbb16e4b0ab4eebbf6cd0&Tag.3.Key=owner_name&Tag.3.Value=Nikolay%20Sokolov&Tag.4.Key=account_id&Tag.4.Value=54886774e4b07f52e92c6366&Tag.5.Key=instance_name&Tag.5.Value=Sunset%20Dust%20Chef%20Custom%20Version&Tag.6.Key=account_name&Tag.6.Value=nsokolov-lime-tests&Tag.7.Key=application_name&Tag.7.Value=Chef%20Custom%20Version&Tag.8.Key=instance_id&Tag.8.Value=54886996e4b07f52e92c6416&Tag.9.Key=application_id&Tag.9.Value=54886804e4b07f52e92c63a2&ResourceId.1=i-55928eb4"
jclouds.headers: >> POST https://ec2.us-east-1.amazonaws.com/ HTTP/1.1
jclouds.headers: >> Host: ec2.us-east-1.amazonaws.com
jclouds.headers: >> X-Amz-Date: 20141210T154200Z
jclouds.headers: >> Authorization: AWS4-HMAC-SHA256
Credential=AKIAJAN2X6RN5VISZ3DA/20141210/us-east-1/ec2/aws4_request,
SignedHeaders=content-type;host;x-amz-date,
Signature=6dbf5e35c6db5febacf05ad761219f3912cbbbeefa4c4b790ea4f1eaaeb2
jclouds.headers: >> Content-Type: application/x-www-form-urlencoded
jclouds.headers: >> Content-Length: 603
s.n.w.p.h.HttpURLConnection: sun.net.www.MessageHeader@70896b489 pairs: {POST /
HTTP/1.1: null}{X-Amz-Date: 20141210T154200Z}{Authorization: AWS4-HMAC-SHA256
Credential=AKIAJAN2X6RN5VISZ3DA/20141210/us-east-1/ec2/aws4_request,
SignedHeaders=content-type;host;x-amz-date,
Signature=6dbf5e35c6db5febacf05ad761219f3912cbbbeefa4c4b790ea4f1eaaeb2}{User-Agent:
jclouds/1.7.4-SNAPSHOT java/1.7.0_65}{Content-Type:
application/x-www-form-urlencoded}{Host: ec2.us-east-1.amazonaws.com}{Accept:
text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2}{Connection:
keep-alive}{Content-Length: 603}
s.n.w.p.h.HttpURLConnection: sun.net.www.MessageHeader@4de27db05 pairs: {null:
HTTP/1.1 400 Bad Request}{Transfer-Encoding: chunked}{Date: Wed, 10 Dec 2014
15:41:59 GMT}{Cneonction: close}{Server: AmazonEC2}
o.j.h.i.JavaUrlHttpCommandExecutorService: Receiving response -1118951214:
HTTP/1.1 400 Bad Request
jclouds.headers: << HTTP/1.1 400 Bad Request
jclouds.headers: << Date: Wed, 10 Dec 2014 15:41:59 GMT
jclouds.headers: << Transfer-Encoding: chunked
jclouds.headers: << Server: AmazonEC2
jclouds.headers: << Cneonction: close
jclouds.headers: << Content-Type: application/unknown
jclouds.wire: << "[\n]"
jclouds.wire: <<
"InvalidActionThe action
CreateTags is not valid for this web
service.41008176-6d86-4a80-bdc3-cbc8e220c732"
```
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/commit/bbd5175c19ccb499f3e39ddd9d997c7b194bc601#commitcomment-8916487
[jira] [Issue Comment Deleted] (JCLOUDS-793) make blobstore put operations report server errors via HttpResponseException
[
https://issues.apache.org/jira/browse/JCLOUDS-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Hsueh updated JCLOUDS-793:
-
Comment: was deleted
(was: ... I would also propose that GETs report 4xx/5xx ...)
> make blobstore put operations report server errors via HttpResponseException
>
>
> Key: JCLOUDS-793
> URL: https://issues.apache.org/jira/browse/JCLOUDS-793
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-blobstore
>Affects Versions: 1.8.1
>Reporter: Daniel Hsueh
> Labels: features
>
> observed with openstack-swift 1.8.1 ObjectApi.put()
> if the server responds with a 4xx/5xx response, the put() call returns null
> for the etag
> would it be more useful if there was an HttpResponseException were thrown,
> with the actual request, response, and response code available? as of now,
> the null response only indicates that an etag was not found in the response,
> not that the whole request failed
> I observe that a failure to communicate (e.g. BackoffLimitedRetryHandler
> running through its retires) will result in an HttpResponseException
> there may also be an issue with consistency -- from perusing the
> AzureBlobClient and S3Client code it seems like an HttpException("did not
> receive ETag") would be thrown, and not a null etag
> I would also propose that GETs report 4xx/5xx responses via
> HttpResponseException as well
> I realize this is a major departure from existing behavior, perhaps this
> exception-reporting-on-error could be enabled via an override?
> thank you
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCLOUDS-793) make blobstore put operations report server errors via HttpResponseException
[
https://issues.apache.org/jira/browse/JCLOUDS-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Hsueh updated JCLOUDS-793:
-
Description:
observed with openstack-swift 1.8.1 ObjectApi.put()
if the server responds with a 4xx/5xx response, the put() call returns null for
the etag
would it be more useful if there was an HttpResponseException were thrown, with
the actual request, response, and response code available? as of now, the null
response only indicates that an etag was not found in the response, not that
the whole request failed
I observe that a failure to communicate (e.g. BackoffLimitedRetryHandler
running through its retires) will result in an HttpResponseException
there may also be an issue with consistency -- from perusing the
AzureBlobClient and S3Client code it seems like an HttpException("did not
receive ETag") would be thrown, and not a null etag
I would also propose that GETs report 4xx/5xx responses via
HttpResponseException as well
I realize this is a major departure from existing behavior, perhaps this
exception-reporting-on-error could be enabled via an override?
thank you
was:
observed with openstack-swift 1.8.1 ObjectApi.put()
if the server responds with a 4xx/5xx response, the put() call returns null for
the etag
would it be more useful if there was an HttpResponseException were thrown, with
the actual request, response, and response code available? as of now, the null
response only indicates that an etag was not found in the response, not that
the whole request failed
I observe that a failure to communicate (e.g. BackoffLimitedRetryHandler
running through its retires) will result in an HttpResponseException
there may also be an issue with consistency -- from perusing the
AzureBlobClient and S3Client code it seems like an HttpException("did not
receive ETag") would be thrown, and not a null etag
I would also propose that PUTs report 4xx/5xx responses via
HttpResponseException as well
I realize this is a major departure from existing behavior, perhaps this
exception-reporting-on-error could be enabled via an override?
thank you
> make blobstore put operations report server errors via HttpResponseException
>
>
> Key: JCLOUDS-793
> URL: https://issues.apache.org/jira/browse/JCLOUDS-793
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-blobstore
>Affects Versions: 1.8.1
>Reporter: Daniel Hsueh
> Labels: features
>
> observed with openstack-swift 1.8.1 ObjectApi.put()
> if the server responds with a 4xx/5xx response, the put() call returns null
> for the etag
> would it be more useful if there was an HttpResponseException were thrown,
> with the actual request, response, and response code available? as of now,
> the null response only indicates that an etag was not found in the response,
> not that the whole request failed
> I observe that a failure to communicate (e.g. BackoffLimitedRetryHandler
> running through its retires) will result in an HttpResponseException
> there may also be an issue with consistency -- from perusing the
> AzureBlobClient and S3Client code it seems like an HttpException("did not
> receive ETag") would be thrown, and not a null etag
> I would also propose that GETs report 4xx/5xx responses via
> HttpResponseException as well
> I realize this is a major departure from existing behavior, perhaps this
> exception-reporting-on-error could be enabled via an override?
> thank you
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-793) make blobstore put operations report server errors via HttpResponseException
[
https://issues.apache.org/jira/browse/JCLOUDS-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14241368#comment-14241368
]
Daniel Hsueh commented on JCLOUDS-793:
--
... I would also propose that GETs report 4xx/5xx ...
> make blobstore put operations report server errors via HttpResponseException
>
>
> Key: JCLOUDS-793
> URL: https://issues.apache.org/jira/browse/JCLOUDS-793
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-blobstore
>Affects Versions: 1.8.1
>Reporter: Daniel Hsueh
> Labels: features
>
> observed with openstack-swift 1.8.1 ObjectApi.put()
> if the server responds with a 4xx/5xx response, the put() call returns null
> for the etag
> would it be more useful if there was an HttpResponseException were thrown,
> with the actual request, response, and response code available? as of now,
> the null response only indicates that an etag was not found in the response,
> not that the whole request failed
> I observe that a failure to communicate (e.g. BackoffLimitedRetryHandler
> running through its retires) will result in an HttpResponseException
> there may also be an issue with consistency -- from perusing the
> AzureBlobClient and S3Client code it seems like an HttpException("did not
> receive ETag") would be thrown, and not a null etag
> I would also propose that PUTs report 4xx/5xx responses via
> HttpResponseException as well
> I realize this is a major departure from existing behavior, perhaps this
> exception-reporting-on-error could be enabled via an override?
> thank you
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JCLOUDS-793) make blobstore put operations report server errors via HttpResponseException
Daniel Hsueh created JCLOUDS-793:
Summary: make blobstore put operations report server errors via
HttpResponseException
Key: JCLOUDS-793
URL: https://issues.apache.org/jira/browse/JCLOUDS-793
Project: jclouds
Issue Type: Improvement
Components: jclouds-blobstore
Affects Versions: 1.8.1
Reporter: Daniel Hsueh
observed with openstack-swift 1.8.1 ObjectApi.put()
if the server responds with a 4xx/5xx response, the put() call returns null for
the etag
would it be more useful if there was an HttpResponseException were thrown, with
the actual request, response, and response code available? as of now, the null
response only indicates that an etag was not found in the response, not that
the whole request failed
I observe that a failure to communicate (e.g. BackoffLimitedRetryHandler
running through its retires) will result in an HttpResponseException
there may also be an issue with consistency -- from perusing the
AzureBlobClient and S3Client code it seems like an HttpException("did not
receive ETag") would be thrown, and not a null etag
I would also propose that PUTs report 4xx/5xx responses via
HttpResponseException as well
I realize this is a major departure from existing behavior, perhaps this
exception-reporting-on-error could be enabled via an override?
thank you
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
