Re: [jclouds-labs-openstack] WIP: JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread Ignasi Barrera
Thanks @jasdeep-hundal! Will merge the Keystone PR later today.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82#issuecomment-37908051

Re: [jclouds-karaf] Added support for the DigitalOcean provider (#39)

2014-03-18 Thread Ignasi Barrera
Closed #39.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-karaf/pull/39

Re: [jclouds-karaf] Added support for the DigitalOcean provider (#39)

2014-03-18 Thread Ignasi Barrera
Squashed, rebased and merged. Many thanks @demobox and @iocanel !

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-karaf/pull/39#issuecomment-37909638

[jclouds-cli] Added support for the DigitalOcean provider (#17)

2014-03-18 Thread Ignasi Barrera

You can merge this Pull Request by running:

  git pull https://github.com/jclouds/jclouds-cli do17x

Or you can view, comment on it, or merge it online at:

  https://github.com/jclouds/jclouds-cli/pull/17

-- Commit Summary --

  * Added support for the DigitalOcean provider

-- File Changes --

M assembly/pom.xml (1)

-- Patch Links --

https://github.com/jclouds/jclouds-cli/pull/17.patch
https://github.com/jclouds/jclouds-cli/pull/17.diff

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-cli/pull/17


Re: [jclouds-cli] Added support for the DigitalOcean provider (#17)

2014-03-18 Thread CloudBees pull request builder plugin
[jclouds-cli-pull-requests 
#17](https://jclouds.ci.cloudbees.com/job/jclouds-cli-pull-requests/17/) FAILURE
Looks like there's a problem with this pull request

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-cli/pull/17#issuecomment-37910144

Re: [jclouds-cli] Added support for the DigitalOcean provider (#17)

2014-03-18 Thread Ignasi Barrera
The feature is not yet in the local repo. Will have to wait a bit :)

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-cli/pull/17#issuecomment-37910210

Re: [jclouds-cli] Added support for the DigitalOcean provider (#17)

2014-03-18 Thread Ignasi Barrera
The karaf 1.7.x build has just finished. Let's see if it can find the feature 
now...

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-cli/pull/17#issuecomment-37913207

Re: [jclouds-cli] Added support for the DigitalOcean provider (#17)

2014-03-18 Thread Ignasi Barrera
Closed #17.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-cli/pull/17

Re: [jclouds-cli] Added support for the DigitalOcean provider (#17)

2014-03-18 Thread CloudBees pull request builder plugin
[jclouds-cli-pull-requests 
#18](https://jclouds.ci.cloudbees.com/job/jclouds-cli-pull-requests/18/) SUCCESS
This pull request looks good

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-cli/pull/17#issuecomment-37913796

Re: [jclouds-cli] Added support for the DigitalOcean provider (#17)

2014-03-18 Thread Ignasi Barrera
Merged!

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-cli/pull/17#issuecomment-37913833

Re: [jclouds-labs] BlobStore API for Orion based back-ends (#45)

2014-03-18 Thread Oliver Kopp
Any news on this PR?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/45#issuecomment-37945418

[jira] [Commented] (JCLOUDS-446) Script doesn't run

2014-03-18 Thread Izek Greenfield (JIRA)

[ 
https://issues.apache.org/jira/browse/JCLOUDS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939393#comment-13939393
 ] 

Izek Greenfield commented on JCLOUDS-446:
-

Yes

> Script doesn't run 
> ---
>
> Key: JCLOUDS-446
> URL: https://issues.apache.org/jira/browse/JCLOUDS-446
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-compute
>Affects Versions: 1.7.0, 1.8.0
>Reporter: Izek Greenfield
>
> Hi,
> i have this script: 
> `rm -rf /etc/puppet/prodpuppet
> cd /etc/puppet
> git clone http://10.234.0.72/prodpuppet /etc/puppet/prodpuppet
> for file in `find /etc/puppet/prodpuppet -iname *.sh`
> do
>   chmod 700 $file
> done
> rm -rf /etc/puppet/chpuppet
> git clone http://10.234.0.72/chpuppet /etc/puppet/chpuppet
> for file in `find /etc/puppet/chpuppet -iname *.sh`
> do
>   chmod 700 $file
> done
> cd -
> echo '
> class role::scopeBase {
>require bin_repo::client
>#require sysstat
>require set_env
>#require expect
>require admin::ssh_disable_host_key_check
>require admin::augeas
>require admin::log
>require admin::ntp
>require admin::yum
> }
> class role::scope inherits role::scopeBase {
>   #
>   # hostname izek-as-mongo0
>   #
> include mongodb_tar
> include emm
> }' > /etc/puppet/chpuppet/modules/role/manifests/scope.pp
> echo 
> '{"rpm::folder":"/opt/nds/rpms","mongodb_tar::version":"2.4.5.1","bin_repo::url":"http://10.234.0.72/dependencies","bin_repo::host":"10.234.0.72","emm::version":"3.51.0-2","bin_repo::dir":"/opt/nds/rpms","install_dir":"/opt/nds/installed/","bin_repo::components::url":"http://10.234.0.72/components"}'
>  > /etc/puppet/chpuppet/hieradata/role/scope.json
> chmod 600 /etc/puppet/chpuppet/hieradata/role/scope.json
> augtool set /files/etc/puppet/puppet.conf/main/environment scope
> augtool set /files/etc/puppet/puppet.conf/main/modulepath 
> /etc/puppet/modules:/usr/share/puppet/modules:/etc/puppet/prodpuppet/modules:/etc/puppet/chpuppet/modules:/etc/puppet/chpuppet/forge
> ln -s /etc/puppet/chpuppet/hieradata/hiera.yaml /etc/puppet/hiera.yaml
> ln -s /etc/puppet/chpuppet/hieradata /etc/hieradata
> cd /etc/puppet
> export FACTER_vmrole=scope; export FACTER_fqdn=com; 
> /etc/puppet/chpuppet/provisioning/puppet/puppet_check.sh role::scope
> cd -`
> when running from java the git clone do nothing. when log into the machine 
> and run the script it is OK.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Created] (JCLOUDS-504) search for group name in tags

2014-03-18 Thread Izek Greenfield (JIRA)
Izek Greenfield created JCLOUDS-504:
---

 Summary: search for group name in tags
 Key: JCLOUDS-504
 URL: https://issues.apache.org/jira/browse/JCLOUDS-504
 Project: jclouds
  Issue Type: Improvement
  Components: jclouds-compute
Affects Versions: 1.8.0
Reporter: Izek Greenfield


By now aws-ec2 search for group in the securityGroup name and keyPair. it will 
be grate to add search in tags for tag called "jclouds#group" 



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (JCLOUDS-317) OpenStack Nova v2.0 Domain Server Status missing from OpenStack API

2014-03-18 Thread Jacob Mourelos (JIRA)

[ 
https://issues.apache.org/jira/browse/JCLOUDS-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939444#comment-13939444
 ] 

Jacob Mourelos commented on JCLOUDS-317:


Looking at the [havana source 
code|https://github.com/openstack/nova/blob/master/nova/api/openstack/common.py]
 it looks like there are additional states not present in the documentation 
like: MIGRATING, SHELVED, etc.

> OpenStack Nova v2.0 Domain Server Status missing from OpenStack API
> ---
>
> Key: JCLOUDS-317
> URL: https://issues.apache.org/jira/browse/JCLOUDS-317
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-compute
>Affects Versions: 1.7.0, 1.6.2
>Reporter: Qin An
>Priority: Blocker
>
> In OpenStack Compute API v2 and Extensions Reference:
> http://docs.openstack.org/api/openstack-compute/2/content/
> Section 2.1.1 List Servers:
> http://docs.openstack.org/api/openstack-compute/2/content/List_Servers-d1e2078.html
> One can find the expected Server Status Values.
> However in jClouds(I checked both 1.6 and 1.7), some of these server status 
> are missing.
> They are: RESCUE and SHUTOFF
> Some of the server status are not in OpenStack API documents:
> PAUSED and STOPPED
> Among these differences, I guess SHUTOFF replaced the original STOPPED from 
> v1 and PAUSED is removed from v1.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


Re: [jclouds-cli] Added support for the DigitalOcean provider (#17)

2014-03-18 Thread Andrew Phillips
+1 - looks good to me. Thanks, @nacx!

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-cli/pull/17#issuecomment-37956576

Re: [jclouds-karaf] Added support for the DigitalOcean provider (#39)

2014-03-18 Thread Andrew Phillips
Commit is 
[here](https://git-wip-us.apache.org/repos/asf?p=jclouds-karaf.git;a=commit;h=176deecd8e3f98165c41c6d72055b597ac0ed3d0)

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-karaf/pull/39#issuecomment-37957108

Re: [jclouds] JCLOUDS-492 (#318)

2014-03-18 Thread Andrew Phillips
> The test failures was a bummer. I thought a commit to Github will only
> update my fork branch and I can send it for a review.

You don't have to worry about the test failures. The Jenkins builds are 
automatically adding your diff to a copy of the code and running tests - 
nothing is changed in the main repo.

You can, of course, always run tests locally, but you don't need to be 
concerned about failures here ;-)


---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/318#issuecomment-37957698

Re: [jclouds-labs-openstack] WIP: JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread jasdeep-hundal
@nacx: Thanks for doing that. Should I squash/rebase this PR for merging as 
well?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82#issuecomment-37957831

Re: [jclouds] JCLOUDS-492 (#318)

2014-03-18 Thread Andrew Phillips
> @@ -44,7 +44,12 @@
>  
> private int deviceIndex = 1;
>  
> -   /**
> +public RegisterImageBackedByEbsOptions() {
> +formParameters.put("BlockDeviceMapping.0.DeviceName", "/dev/sda1");
> +formParameters.put("RootDeviceName","/dev/sda1");

And a minor comment: missing space before `"/dev/sda1"`

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/318/files#r10712892

Re: [jclouds] JCLOUDS-492 (#318)

2014-03-18 Thread Andrew Phillips
> @@ -130,6 +135,22 @@ public RegisterImageBackedByEbsOptions 
> addNewBlockDevice(String deviceName,
>return this;
> }
>  
> +/**
> + *
> + * sets the ROOT device name to the specified name.

"Sets" (capital 'S"), and please remove the blank line above. I know "adds" 
above is also lowercase, but we don't have to continue that trend ;-)

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/318/files#r10712949

Re: [jclouds] JCLOUDS-492 (#318)

2014-03-18 Thread Andrew Phillips
> @@ -130,6 +135,22 @@ public RegisterImageBackedByEbsOptions 
> addNewBlockDevice(String deviceName,
>return this;
> }
>  
> +/**
> + *
> + * sets the ROOT device name to the specified name.
> + *
> + * @param name
> + *   The device name (e.g., /dev/sdh).

Simply "The device name, e.g. /dev/sdh"?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/318/files#r10712968

Re: [jclouds] JCLOUDS-492 (#318)

2014-03-18 Thread Andrew Phillips
> @@ -130,6 +135,22 @@ public RegisterImageBackedByEbsOptions 
> addNewBlockDevice(String deviceName,
>return this;
> }
>  
> +/**
> + *
> + * sets the ROOT device name to the specified name.
> + *
> + * @param name
> + *   The device name (e.g., /dev/sdh).
> + *
> + */
> +public RegisterImageBackedByEbsOptions setRootDeviceName(String 
> deviceName) {
> +formParameters.removeAll("BlockDeviceMapping.0.DeviceName");
> +formParameters.removeAll("RootDeviceName");

Agree with @nacx's comment above - we don't really want setters removing items.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/318/files#r10715428

Re: [jclouds] JCLOUDS-492 (#318)

2014-03-18 Thread Andrew Phillips
> + *   Options to specify metadata such as architecture or 
> secondary volumes to be
> + *   associated with this image.
> + * @return imageId
> + *
> + * @see #describeImages
> + * @see #deregisterImage
> + * @see  + *  
> "http://docs.amazonwebservices.com/AWSEC2/latest/APIReference/ApiReference-query-RegisterImage.html";
> + *  />
> + */
> +@Named("RegisterImageWithOptions")
> +@POST
> +@Path("/")
> +@FormParams(keys = { ACTION }, values = { "RegisterImage"})
> +@XMLResponseParser(ImageIdHandler.class)
> +String registerUnixImgBackedByEbsInRegion(

Rename to registerUnixImageBackedByEbsInRegion - see @nacx's comment above

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/318/files#r10715467

Re: [jclouds] JCLOUDS-492 (#318)

2014-03-18 Thread Andrew Phillips
> +
> +request = (GeneratedHttpRequest) 
> request.getFilters().get(0).filter(request);
> +
> +assertRequestLineEquals(request, "POST 
> https://ec2.us-east-1.amazonaws.com/ HTTP/1.1");
> +assertNonPayloadHeadersEqual(request, "Host: 
> ec2.us-east-1.amazonaws.com\n");
> +assertPayloadEquals(request, 
> actualRegisterImgBackedByEBSOptions.getPayload().getRawContent().toString(),
> +"application/x-www-form-urlencoded", false);
> +
> +assertResponseParserClassEquals(method, request, ParseSax.class);
> +assertSaxResponseParserClassEquals(method, ImageIdHandler.class);
> +assertFallbackClassEquals(method, null);
> +
> +checkFilters(request);
> +}
> +
> +HttpRequest getBlockDeviceMappingsForImage = 
> HttpRequest.builder().method("POST")

Indents are incorrect here - jclouds uses a 3-space indent

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/318/files#r10715507

Re: [jclouds] JCLOUDS-492 (#318)

2014-03-18 Thread jaiganeshm
Thanks Andrew for the clarification. That is a relief to know that the main
repo is not touched :)

Rgds
Jai


On Tue, Mar 18, 2014 at 9:54 AM, Andrew Phillips
wrote:

> The test failures was a bummer. I thought a commit to Github will only
> update my fork branch and I can send it for a review.
>
> You don't have to worry about the test failures. The Jenkins builds are
> automatically adding your diff to a copy of the code and running tests -
> nothing is changed in the main repo.
>
> You can, of course, always run tests locally, but you don't need to be
> concerned about failures here ;-)
>
> --
> Reply to this email directly or view it on 
> GitHub
> .
>

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/318#issuecomment-37970184

[jclouds] JCLOUDS-184: Improving AzureBlob unit tests for AzureBlobBlockUploadStrategyTest (#320)

2014-03-18 Thread kstyrc

You can merge this Pull Request by running:

  git pull https://github.com/kstyrc/jclouds master

Or you can view, comment on it, or merge it online at:

  https://github.com/jclouds/jclouds/pull/320

-- Commit Summary --

  * JCLOUDS-184: Improving AzureBlob unit tests
  * JCLOUDS-184: Improving AzureBlob unit tests

-- File Changes --

M 
providers/azureblob/src/test/java/org/jclouds/azureblob/blobstore/strategy/AzureBlobBlockUploadStrategyTest.java
 (39)

-- Patch Links --

https://github.com/jclouds/jclouds/pull/320.patch
https://github.com/jclouds/jclouds/pull/320.diff

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/320


[jira] [Commented] (JCLOUDS-184) Improve AzureBlob Unit Tests

2014-03-18 Thread Krzysztof Styrc (JIRA)

[ 
https://issues.apache.org/jira/browse/JCLOUDS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939649#comment-13939649
 ] 

Krzysztof Styrc commented on JCLOUDS-184:
-

https://github.com/jclouds/jclouds/pull/320

> Improve AzureBlob Unit Tests
> 
>
> Key: JCLOUDS-184
> URL: https://issues.apache.org/jira/browse/JCLOUDS-184
> Project: jclouds
>  Issue Type: Improvement
>Reporter: John Kew
>
> Use verify to check order and check some error conditions in 
> AzureBlobUploadStrategyTest



--
This message was sent by Atlassian JIRA
(v6.2#6252)


Re: [jclouds] JCLOUDS-184: Improving AzureBlob unit tests for AzureBlobBlockUploadStrategyTest (#320)

2014-03-18 Thread CloudBees pull request builder plugin
[jclouds-pull-requests 
#667](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/667/) SUCCESS
This pull request looks good

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/320#issuecomment-37978819

Re: [jclouds] JCLOUDS-184: Improving AzureBlob unit tests for AzureBlobBlockUploadStrategyTest (#320)

2014-03-18 Thread CloudBees pull request builder plugin
[jclouds-java-7-pull-requests 
#1137](https://jclouds.ci.cloudbees.com/job/jclouds-java-7-pull-requests/1137/) 
SUCCESS
This pull request looks good

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/320#issuecomment-37979552

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread Andrew Phillips
> +import com.google.common.base.Supplier;
> +import com.google.common.base.Throwables;
> +import com.google.common.cache.CacheBuilder;
> +import com.google.common.cache.CacheLoader;
> +import com.google.common.cache.LoadingCache;
> +
> +/**
> + * 
> + * @author Jasdeep Hundal
> + */
> +@Singleton
> +public class ZoneToEndpointNegotiateVersion implements Function 
> {
> +
> +   public static final String VERSION_NEGOTIATION_HEADER = 
> "Is-Version-Negotiation-Request";
> +
> +   private static class VersionsJsonResponse{

I don't think we keep domain objects such as this one in functions much. Is 
this a pattern you've copied from elsewhere in the jclouds code?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10723873

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread Andrew Phillips
> + public String status;
> + public String id;
> + public List links;
> +  }
> +  public List versions;
> +   }
> +
> +   private final Supplier>> zoneToEndpointSupplier;
> +   private final String apiVersion;
> +   private final LoadingCache endpointCache;
> +
> +   @Inject
> +   public ZoneToEndpointNegotiateVersion(@Zone Supplier Supplier>> zoneToEndpointSupplier,
> + @ApiVersion String apiVersionString, final HttpClient client, final 
> Json json) {
> +  this.zoneToEndpointSupplier = checkNotNull(zoneToEndpointSupplier, 
> "zoneToEndpointSupplier");
> +  if(!apiVersionString.startsWith("v"))

Why do we need this logic...backwards-compatibility? Can't we just enforce the 
fact that it has to start with a "v"?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10723902

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread Andrew Phillips
> +  this.zoneToEndpointSupplier = checkNotNull(zoneToEndpointSupplier, 
> "zoneToEndpointSupplier");
> +  if(!apiVersionString.startsWith("v"))
> + apiVersionString = "v" + apiVersionString;
> +  this.apiVersion = apiVersionString;
> +  this.endpointCache = CacheBuilder.newBuilder()
> + .build(
> +new CacheLoader() {
> +   public URI load(URI baseEndpointUri) {
> +  URI versionEndpointUri = null;
> +  try {
> + HttpRequest negotiationRequest = HttpRequest.builder()
> +.method("GET").endpoint(baseEndpointUri)
> +.addHeader(VERSION_NEGOTIATION_HEADER, 
> "true").build();
> + InputStream response = 
> client.invoke(negotiationRequest).getPayload().openStream();
> + VersionsJsonResponse versions = 
> json.fromJson(Strings2.toStringAndClose(response), 
> VersionsJsonResponse.class);
> + for( VersionsJsonResponse.Version version : 
> versions.versions ) {

Formatting: "for (V...s)"

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10723963

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread Andrew Phillips
> +  if(!apiVersionString.startsWith("v"))
> + apiVersionString = "v" + apiVersionString;
> +  this.apiVersion = apiVersionString;
> +  this.endpointCache = CacheBuilder.newBuilder()
> + .build(
> +new CacheLoader() {
> +   public URI load(URI baseEndpointUri) {
> +  URI versionEndpointUri = null;
> +  try {
> + HttpRequest negotiationRequest = HttpRequest.builder()
> +.method("GET").endpoint(baseEndpointUri)
> +.addHeader(VERSION_NEGOTIATION_HEADER, 
> "true").build();
> + InputStream response = 
> client.invoke(negotiationRequest).getPayload().openStream();
> + VersionsJsonResponse versions = 
> json.fromJson(Strings2.toStringAndClose(response), 
> VersionsJsonResponse.class);
> + for( VersionsJsonResponse.Version version : 
> versions.versions ) {
> +if(apiVersion.equals(version.id)) {

Formatting: space after "if"

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10723978

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread Andrew Phillips
> + .build(
> +new CacheLoader() {
> +   public URI load(URI baseEndpointUri) {
> +  URI versionEndpointUri = null;
> +  try {
> + HttpRequest negotiationRequest = HttpRequest.builder()
> +.method("GET").endpoint(baseEndpointUri)
> +.addHeader(VERSION_NEGOTIATION_HEADER, 
> "true").build();
> + InputStream response = 
> client.invoke(negotiationRequest).getPayload().openStream();
> + VersionsJsonResponse versions = 
> json.fromJson(Strings2.toStringAndClose(response), 
> VersionsJsonResponse.class);
> + for( VersionsJsonResponse.Version version : 
> versions.versions ) {
> +if(apiVersion.equals(version.id)) {
> +   String newURIString = version.links.get(0).href;
> +   if(newURIString.startsWith("http:") && 
> baseEndpointUri.toString().startsWith("https:"))
> +  newURIString = "https" + 
> newURIString.substring(4);
> +   versionEndpointUri = new URI(newURIString);

Can we use 
[Uris](https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/Uris.java),
 for this, rather than doing string manipulation directly?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10724016

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread Andrew Phillips
> +  try {
> + HttpRequest negotiationRequest = HttpRequest.builder()
> +.method("GET").endpoint(baseEndpointUri)
> +.addHeader(VERSION_NEGOTIATION_HEADER, 
> "true").build();
> + InputStream response = 
> client.invoke(negotiationRequest).getPayload().openStream();
> + VersionsJsonResponse versions = 
> json.fromJson(Strings2.toStringAndClose(response), 
> VersionsJsonResponse.class);
> + for( VersionsJsonResponse.Version version : 
> versions.versions ) {
> +if(apiVersion.equals(version.id)) {
> +   String newURIString = version.links.get(0).href;
> +   if(newURIString.startsWith("http:") && 
> baseEndpointUri.toString().startsWith("https:"))
> +  newURIString = "https" + 
> newURIString.substring(4);
> +   versionEndpointUri = new URI(newURIString);
> +   break;
> +}
> + }
> +  } catch (Exception ex) {

What Exceptions are we catching here? Why do we need this catch block, and can 
we catch a narrower exception?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10724045

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread Andrew Phillips
> + VersionsJsonResponse versions = 
> json.fromJson(Strings2.toStringAndClose(response), 
> VersionsJsonResponse.class);
> + for( VersionsJsonResponse.Version version : 
> versions.versions ) {
> +if(apiVersion.equals(version.id)) {
> +   String newURIString = version.links.get(0).href;
> +   if(newURIString.startsWith("http:") && 
> baseEndpointUri.toString().startsWith("https:"))
> +  newURIString = "https" + 
> newURIString.substring(4);
> +   versionEndpointUri = new URI(newURIString);
> +   break;
> +}
> + }
> +  } catch (Exception ex) {
> + throw Throwables.propagate(ex);
> +  }
> +  if (versionEndpointUri == null)
> + throw new HttpException("Glance endpoint does not 
> support API version: " + apiVersion);
> +  return versionEndpointUri;

Why can't we just return the first one we find in the loop?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10724084

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread Andrew Phillips
> +   break;
> +}
> + }
> +  } catch (Exception ex) {
> + throw Throwables.propagate(ex);
> +  }
> +  if (versionEndpointUri == null)
> + throw new HttpException("Glance endpoint does not 
> support API version: " + apiVersion);
> +  return versionEndpointUri;
> +  }
> + });
> +   }
> +
> +   @Override
> +   public URI apply(Object from) {
> +  checkArgument(from != null && from instanceof String, "you must 
> specify a zone, as a String argument");

We don't need the `!= null` check, null is not `instanceof String`

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10724109

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread Andrew Phillips
> + }
> +  } catch (Exception ex) {
> + throw Throwables.propagate(ex);
> +  }
> +  if (versionEndpointUri == null)
> + throw new HttpException("Glance endpoint does not 
> support API version: " + apiVersion);
> +  return versionEndpointUri;
> +  }
> + });
> +   }
> +
> +   @Override
> +   public URI apply(Object from) {
> +  checkArgument(from != null && from instanceof String, "you must 
> specify a zone, as a String argument");
> +  Map> zoneToEndpoint = 
> zoneToEndpointSupplier.get();
> +  checkState(zoneToEndpoint.size() > 0, "no zone name to endpoint 
> mappings configured!");

`!zoneToEndpoint.isEmpty()`?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10724130

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread Andrew Phillips
> @@ -46,6 +47,11 @@ public void handleError(HttpCommand command, HttpResponse 
> response) {
>message = message != null ? message : String.format("%s -> %s", 
> command.getCurrentRequest().getRequestLine(),
> response.getStatusLine());
>switch (response.getStatusCode()) {
> + // This is exclusively to not throw exceptions on Glance version 
> negotiation
> + case 300:
> +if 
> (command.getCurrentRequest().getFirstHeaderOrNull(ZoneToEndpointNegotiateVersion.VERSION_NEGOTIATION_HEADER)
>  != null)

Static import `ZoneToEndpointNegotiateVersion.VERSION_NEGOTIATION_HEADER`? But 
what causes the 300 response from Glance in the firest place?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10724608

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread jasdeep-hundal
> +import com.google.common.base.Supplier;
> +import com.google.common.base.Throwables;
> +import com.google.common.cache.CacheBuilder;
> +import com.google.common.cache.CacheLoader;
> +import com.google.common.cache.LoadingCache;
> +
> +/**
> + * 
> + * @author Jasdeep Hundal
> + */
> +@Singleton
> +public class ZoneToEndpointNegotiateVersion implements Function 
> {
> +
> +   public static final String VERSION_NEGOTIATION_HEADER = 
> "Is-Version-Negotiation-Request";
> +
> +   private static class VersionsJsonResponse{

Nope, this was just something that works. Didn't know the JClouds way of doing 
things here, open to suggestions.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10724655

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread jasdeep-hundal
> + public String status;
> + public String id;
> + public List links;
> +  }
> +  public List versions;
> +   }
> +
> +   private final Supplier>> zoneToEndpointSupplier;
> +   private final String apiVersion;
> +   private final LoadingCache endpointCache;
> +
> +   @Inject
> +   public ZoneToEndpointNegotiateVersion(@Zone Supplier Supplier>> zoneToEndpointSupplier,
> + @ApiVersion String apiVersionString, final HttpClient client, final 
> Json json) {
> +  this.zoneToEndpointSupplier = checkNotNull(zoneToEndpointSupplier, 
> "zoneToEndpointSupplier");
> +  if(!apiVersionString.startsWith("v"))

Probably was being too cautious here, didn't know if folks would ever specify a 
version with just the number.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10724727

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread Andrew Phillips
> @@ -0,0 +1,44 @@
> +{

[minor] I think we normally use smaller indents for JSON files? I may be wrong, 
though.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10724813

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread Andrew Phillips
I think we're missing some tests for this new functionality: what should happen 
if the API version is/is not found, validating the http -> https switch etc.

I'm not sure, though, whether the explicit use of HttpClient, as opposed to 
adding the version negotiation call as an explicit API call elsewhere and then 
invoking that, is what we want?

@nacx: thoughts on that?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82#issuecomment-37986049

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread Andrew Phillips
> +import com.google.common.base.Supplier;
> +import com.google.common.base.Throwables;
> +import com.google.common.cache.CacheBuilder;
> +import com.google.common.cache.CacheLoader;
> +import com.google.common.cache.LoadingCache;
> +
> +/**
> + * 
> + * @author Jasdeep Hundal
> + */
> +@Singleton
> +public class ZoneToEndpointNegotiateVersion implements Function 
> {
> +
> +   public static final String VERSION_NEGOTIATION_HEADER = 
> "Is-Version-Negotiation-Request";
> +
> +   private static class VersionsJsonResponse{

@nacx: do you have an example handy? ;-) But whether we need this or not will 
largely depend on the answer to the "use of HttpClient" question, I guess...

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10725021

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread Andrew Phillips
> + public String status;
> + public String id;
> + public List links;
> +  }
> +  public List versions;
> +   }
> +
> +   private final Supplier>> zoneToEndpointSupplier;
> +   private final String apiVersion;
> +   private final LoadingCache endpointCache;
> +
> +   @Inject
> +   public ZoneToEndpointNegotiateVersion(@Zone Supplier Supplier>> zoneToEndpointSupplier,
> + @ApiVersion String apiVersionString, final HttpClient client, final 
> Json json) {
> +  this.zoneToEndpointSupplier = checkNotNull(zoneToEndpointSupplier, 
> "zoneToEndpointSupplier");
> +  if(!apiVersionString.startsWith("v"))

Then I'd say "let's be tough", and simply add a `checkArgument` the requires an 
initial "v" and an appropriate doc comment (no need for a test, I think).

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10725056

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread jasdeep-hundal
> +   break;
> +}
> + }
> +  } catch (Exception ex) {
> + throw Throwables.propagate(ex);
> +  }
> +  if (versionEndpointUri == null)
> + throw new HttpException("Glance endpoint does not 
> support API version: " + apiVersion);
> +  return versionEndpointUri;
> +  }
> + });
> +   }
> +
> +   @Override
> +   public URI apply(Object from) {
> +  checkArgument(from != null && from instanceof String, "you must 
> specify a zone, as a String argument");

This and the next bit were copied from the ZoneToEndpoint class in jclouds 
core. (Just a note in case you want to make the fix there as well).

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10725241

Re: [jclouds] Fix Keystone response for testing to not include Glance version (#319)

2014-03-18 Thread Andrew Phillips
As per a previous discussion: +1 to this if the new response value 
`https://glance.jclouds.org:9292/` is one that could be realistically returned 
by an OpenStack installation. From what I recall, someone (@zack-shoylev? 
@everett-toews?) confirmed that that was indeed the case.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/319#issuecomment-37986969

Re: [jclouds] Fix Keystone response for testing to not include Glance version (#319)

2014-03-18 Thread Andrew Phillips
Thanks, @jasdeep-hundal!

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/319#issuecomment-37987013

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread jasdeep-hundal
> + public String status;
> + public String id;
> + public List links;
> +  }
> +  public List versions;
> +   }
> +
> +   private final Supplier>> zoneToEndpointSupplier;
> +   private final String apiVersion;
> +   private final LoadingCache endpointCache;
> +
> +   @Inject
> +   public ZoneToEndpointNegotiateVersion(@Zone Supplier Supplier>> zoneToEndpointSupplier,
> + @ApiVersion String apiVersionString, final HttpClient client, final 
> Json json) {
> +  this.zoneToEndpointSupplier = checkNotNull(zoneToEndpointSupplier, 
> "zoneToEndpointSupplier");
> +  if(!apiVersionString.startsWith("v"))

OK, after testing it seems that the version number in fact does not start w/ a 
'v' typically

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10725390

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread Andrew Phillips
> + public String status;
> + public String id;
> + public List links;
> +  }
> +  public List versions;
> +   }
> +
> +   private final Supplier>> zoneToEndpointSupplier;
> +   private final String apiVersion;
> +   private final LoadingCache endpointCache;
> +
> +   @Inject
> +   public ZoneToEndpointNegotiateVersion(@Zone Supplier Supplier>> zoneToEndpointSupplier,
> + @ApiVersion String apiVersionString, final HttpClient client, final 
> Json json) {
> +  this.zoneToEndpointSupplier = checkNotNull(zoneToEndpointSupplier, 
> "zoneToEndpointSupplier");
> +  if(!apiVersionString.startsWith("v"))

> OK, after testing it seems that the version number in fact does not start w/ 
> a 'v' typically. (Tests quickly failed on 
> that, their just using '1.0'

Ah, interesting. Any idea why the jclouds code was using a hard-coded `v1.0`? 
Is that supported in some kind of compatibility mode? Do we even need the `v` 
at all, then?

If we do need to keep this, we should at least add a test for it. And I think 
you can call the parameter `apiVersion` and simply do something like:
```
if (!apiVersion.startsWith("v")) {
  this.apiVersion = "v" + apiVersion;
} else {
  this.apiVersion = apiVersion;
}
```

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10725682

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread jasdeep-hundal
> @@ -0,0 +1,44 @@
> +{

I think it was actually 4 in the keystoneAuthResponse.json, but I'm not 
consistent with that either here...

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10725757

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread jasdeep-hundal
> @@ -46,6 +47,11 @@ public void handleError(HttpCommand command, HttpResponse 
> response) {
>message = message != null ? message : String.format("%s -> %s", 
> command.getCurrentRequest().getRequestLine(),
> response.getStatusLine());
>switch (response.getStatusCode()) {
> + // This is exclusively to not throw exceptions on Glance version 
> negotiation
> + case 300:
> +if 
> (command.getCurrentRequest().getFirstHeaderOrNull(ZoneToEndpointNegotiateVersion.VERSION_NEGOTIATION_HEADER)
>  != null)

300 is just what Glance returns as the status code when it offers up possible 
versions. Does seem a bit awkward, but it's what we're dealing with.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10725824

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread jasdeep-hundal
> + public String status;
> + public String id;
> + public List links;
> +  }
> +  public List versions;
> +   }
> +
> +   private final Supplier>> zoneToEndpointSupplier;
> +   private final String apiVersion;
> +   private final LoadingCache endpointCache;
> +
> +   @Inject
> +   public ZoneToEndpointNegotiateVersion(@Zone Supplier Supplier>> zoneToEndpointSupplier,
> + @ApiVersion String apiVersionString, final HttpClient client, final 
> Json json) {
> +  this.zoneToEndpointSupplier = checkNotNull(zoneToEndpointSupplier, 
> "zoneToEndpointSupplier");
> +  if(!apiVersionString.startsWith("v"))

The tricky bit for me was that since we're using the apiVersion field in an 
anonymous class that we construct, the compiler needs to know that the field is 
final, and the compiler wasn't able to disambiguate between a nonfinal 
parameter in the constructor and the final field in the class that both had the 
same name.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82/files#r10726147

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread jasdeep-hundal
@demobox : Thanks for the eyes, pushed the minor fixes mentioned. Will get to 
the tests in a bit.

On the note of an explicit use of HttpClient, I don't think the Image/GlanceApi 
is where this should go. Determining the right versioned endpoint is something 
that needs to happen before and ImageApi request, and I'm not sure how we'd 
include that sort of logic by including this negotiation in the ImageApi itself.

Thinking about it some more, would it be possible/cleaner to use a retryHandler 
instead of an errorHandler to deal with the HttpClient behavior on HTTP 
responses with a 300 status code?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82#issuecomment-37991838

Jenkins build is unstable: jclouds » jclouds-labs-openstack #927

2014-03-18 Thread BuildHive
See 




Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread BuildHive
[jclouds » jclouds-labs-openstack 
#927](https://buildhive.cloudbees.com/job/jclouds/job/jclouds-labs-openstack/927/)
 UNSTABLE
Looks like there's a problem with this pull request
[(what's this?)](https://www.cloudbees.com/what-is-buildhive)

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82#issuecomment-37992059

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread CloudBees pull request builder plugin
[jclouds-labs-openstack-pull-requests 
#182](https://jclouds.ci.cloudbees.com/job/jclouds-labs-openstack-pull-requests/182/)
 UNSTABLE
Looks like there's a problem with this pull request

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82#issuecomment-37992211

Re: [jclouds-site] Modernize BlobStore examples (#59)

2014-03-18 Thread Andrew Gaul
Pushed to master and deployed.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/59#issuecomment-37999805

Re: [jclouds-site] Modernize BlobStore examples (#59)

2014-03-18 Thread Andrew Gaul
Closed #59.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/59

Re: [jclouds-site] Modernize BlobStore examples (#59)

2014-03-18 Thread Andrew Phillips
Thanks!

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/59#issuecomment-38003514

Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)

2014-03-18 Thread Andrew Phillips
> Thinking about it some more, would it be possible/cleaner to use a 
> retryHandler instead of an 
> errorHandler to deal with the HttpClient behavior on HTTP responses with a 
> 300 status code?

Well, the "cleanest" thing I can think of would be to hook in where the 
success/failure of the call is determined, and decide that 300 is actually a 
success response code for this particular call. But not sure how we would go 
about that.

> On the note of an explicit use of HttpClient, I don't think the 
> Image/GlanceApi is where this should go

Agreed. But what is the OpenStack API that we're actually talking to here? Some 
kind of admin/config API?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82#issuecomment-38003773

Re: [jclouds] JCLOUDS-184: Improving AzureBlob unit tests for AzureBlobBlockUploadStrategyTest (#320)

2014-03-18 Thread Andrew Phillips
>  public class AzureBlobBlockUploadStrategyTest {
>  
> +   @Test(groups = "unit", testName = "AzureBlobBlockUploadStrategyTest")

Why has this moved here?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/320/files#r10731992

Re: [jclouds] JCLOUDS-184: Improving AzureBlob unit tests for AzureBlobBlockUploadStrategyTest (#320)

2014-03-18 Thread Andrew Phillips
>  
>  import java.util.List;
>  
> -import static org.easymock.EasyMock.anyObject;
> -import static org.easymock.EasyMock.createMock;
> -import static org.easymock.EasyMock.eq;
> -import static org.easymock.EasyMock.expect;
> -import static org.easymock.EasyMock.expectLastCall;
> -import static org.easymock.EasyMock.replay;
> +import static org.easymock.EasyMock.*;

Please avoid wildcard imports

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/320/files#r10731983

Re: [jclouds] JCLOUDS-184: Improving AzureBlob unit tests for AzureBlobBlockUploadStrategyTest (#320)

2014-03-18 Thread Andrew Phillips
> @@ -70,5 +65,29 @@ public void testExecute() throws Exception {
>replay(slicer,client);
>String etag = strat.execute(container, blob);
>assertEquals(etag, "Fake ETAG");
> +
> +  verify(slicer, client);
> +   }
> +
> +   @Test(groups = "unit", expectedExceptions = 
> IllegalArgumentException.class)
> +   public void testExceededContentLengthLimit() throws Exception {
> +  String container = "test-container";
> +  String blobName = "test-blob";
> +
> +  AzureBlobClient client = createMock(AzureBlobClient.class);
> +  PayloadSlicer slicer = createMock(PayloadSlicer.class);

Don't we at least need to call `replay` on the mocks? And, since we're not 
actually expecting any behaviour, create nice mocks instead?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/320/files#r10732060

Re: [jclouds] JCLOUDS-184: Improving AzureBlob unit tests for AzureBlobBlockUploadStrategyTest (#320)

2014-03-18 Thread Andrew Phillips
> @@ -70,5 +65,29 @@ public void testExecute() throws Exception {
>replay(slicer,client);
>String etag = strat.execute(container, blob);
>assertEquals(etag, "Fake ETAG");
> +
> +  verify(slicer, client);

What is the benefit of this? Are we interested in how often exactly the slicer 
is called? For the client, yes, I can see the point of this 
(unexpected/unnecessary API calls could be expensive). But I don't see how/why 
we care about calls to the slicer?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/320/files#r10732089

Re: [jclouds] Retry on S3 HTTP 504 Gateway Timeout status codes (#317)

2014-03-18 Thread Andrew Phillips
> @@ -112,4 +113,21 @@ public Integer answer() throws Throwable {
>  
> }
>  
> +   @Test
> +   public void test504DoesRetry() {
> +  AWSUtils utils = createMock(AWSUtils.class);
> +  HttpCommand command = createMock(HttpCommand.class);
> +  expect(command.getFailureCount()).andReturn(1).anyTimes();
> +  expect(command.incrementFailureCount()).andReturn(1);
> +  expect(command.isReplayable()).andReturn(true);
> +
> +  replay(utils, command);
> +
> +  AWSServerErrorRetryHandler retry = new 
> AWSServerErrorRetryHandler(utils,
> +ImmutableSet. of());
> +
> +  assertTrue(retry.shouldRetryRequest(command, 
> HttpResponse.builder().statusCode(504).build()));

I guess this returns true because the `super.shouldRetryRequest` call will 
return true?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/317/files#r10735049

Re: [jclouds] Retry on S3 HTTP 504 Gateway Timeout status codes (#317)

2014-03-18 Thread Andrew Phillips
If I understand correctly, the change basically was "delegate decision to retry 
to parent class on 504"? If I'm getting that right, +1 - looks good to me!

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/317#issuecomment-38011814

Re: [jclouds] Updating the features section to match the website (#316)

2014-03-18 Thread Andrew Phillips
> jclouds-java-7-pull-requests #1128 UNSTABLE

Just for the record, that was a [spurious test 
failure](https://jclouds.ci.cloudbees.com/job/jclouds-java-7-pull-requests/org.apache.jclouds$jclouds-compute/1128/testReport/junit/org.jclouds.compute.util/ConcurrentOpenSocketFinderTest/testChecksSocketsConcurrently/).
 Thanks, @rcoedo!

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/316#issuecomment-38014940