Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Rita Zhang]

@nacx  No worries! 

> I think splitting the PR will help you focus and also advance in other areas 
> while the compute service is a WIP. 

That makes sense to me. I will go ahead and split this PR into two as you 
suggested and address some of these comments for the APIs.

---
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/267#issuecomment-220481422

Build failed in Jenkins: jclouds-guava-guice-compat » 19.0-rc1,3.0,OpenJDK 7 (latest) #152

[jenkins-no-reply]

See 


Changes:

[Ignasi Barrera] JCLOUDS-1114: Adding support for "Placement.Tenancy" and

[Ignasi Barrera] client credentials JWT support

--
[...truncated 20065 lines...]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
ERROR: , completed: 0/2, errors: 1, rate: 0ms/op
java.util.concurrent.ExecutionException: java.lang.RuntimeException
at 
com.google.common.util.concurrent.Futures$ImmediateFailedFuture.get(Futures.java:234)
at 
org.jclouds.concurrent.FutureIterables$1.run(FutureIterables.java:123)
at 
com.google.common.util.concurrent.MoreExecutors$DirectExecutorService.execute(MoreExecutors.java:310)
at 
com.google.common.util.concurrent.Futures$ImmediateFuture.addListener(Futures.java:147)
at 
org.jclouds.concurrent.FutureIterables.awaitCompletion(FutureIterables.java:118)
at 
org.jclouds.concurrent.FutureIterables.transformParallel(FutureIterables.java:86)
at 
org.jclouds.concurrent.FutureIterables.transformParallel(FutureIterables.java:70)
at 
org.jclouds.concurrent.FutureIterablesTest.testNormalExceptionPropagatesAsTransformParallelExceptionAndTries5XPerElement(FutureIterablesTest.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:696)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:882)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1189)
at 
org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.RuntimeException
at 
org.jclouds.concurrent.FutureIterablesTest$2.apply(FutureIterablesTest.java:71)
at 
org.jclouds.concurrent.FutureIterablesTest$2.apply(FutureIterablesTest.java:68)
at 
org.jclouds.concurrent.FutureIterables.transformParallel(FutureIterables.java:82)
... 15 more
ERROR: , completed: 0/2, errors: 2, rate: 0ms/op
java.util.concurrent.ExecutionException: java.lang.RuntimeException
at 
com.google.common.util.concurrent.Futures$ImmediateFailedFuture.get(Futures.java:234)
at 
org.jclouds.concurrent.FutureIterables$1.run(FutureIterables.java:123)
at 
com.google.common.util.concurrent.MoreExecutors$DirectExecutorService.execute(MoreExecutors.java:310)
at 
com.google.common.util.concurrent.Futures$ImmediateFuture.addListener(Futures.java:147)
at 
org.jclouds.concurrent.FutureIterables.awaitCompletion(FutureIterables.java:118)
at 
org.jclouds.concurrent.FutureIterables.transformParallel(FutureIterables.java:86)
at 
org.jclouds.concurrent.FutureIterables.transformParallel(FutureIterables.java:70)
at 
org.jclouds.concurrent.FutureIterablesTest.testNormalExceptionPropagatesAsTransformParallelExceptionAndTries5XPerElement(FutureIterablesTest.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:696)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:882)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1189)
at 
org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.RuntimeException
at 
org.jclouds.concurren

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> bump We have folks who are waiting to test this in few days. Would be awesome 
> if we could get this merged soon since we have couple of more PRs left. Thank 
> you so much for all your feedback!!!

Apologies for the delay. I'm just back from ApacheCon in Vancouver and was 
still going through my backlog :)

I think with the current comments there are many things to think about and 
discuss. I think it would make sense to split this into two pull requests: one 
with all the APIs, and one with the compute service implementation and the 
transformation functions. The main reason is:

* APIs will be merged sooner.
* Implementing the compute service will bring some design discussions onto the 
table (as seen). How to design user access to VMs, how to match jclouds 
entities to azure ones, etc.
* We consider the compute service properly implemented once there is a test 
that extends the `BaseComputeServiceLiveTest` (have a look at the 
[digitalocean](https://github.com/jclouds/jclouds/blob/master/providers/digitalocean2/src/test/java/org/jclouds/digitalocean2/compute/DigitalOcean2ComputeServiceLiveTest.java)
 one for an example) and one that extends the `BaseTemplateBuilderLiveTest` 
(again, see the 
[digitalocean](https://github.com/jclouds/jclouds/blob/master/providers/digitalocean2/src/test/java/org/jclouds/digitalocean2/compute/DigitalOcean2TemplateBuilderLiveTest.java)
 one). These tests *are the contract* for the compute service and must be 
passing (with little and minor modifications, if you look at the examples 
you'll see they just add things and override just very few things) to show that 
the jclouds expected functionality is covered.

I think splitting the PR will help you focus and also advance in other areas 
while the compute service is a WIP. It will also help to develop it step by 
step: we can perhaps merge first just the compute service (with a proper design 
and entity mappings) and later on merge the tests and the fixes required to the 
model/impl to make them pass and meet the jclouds contract. WDYT?

Look forward to seeing all this stuff merged!

---
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/267#issuecomment-220476220

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> +  this.locations = checkNotNull(locations, "locations");
> +  this.imageReferenceToImage = imageReferenceToImage;
> +  this.vmSizeToHardware = vmSizeToHardware;
> +  this.credentialStore = credentialStore;
> +  this.api = api;
> +   }
> +
> +   @Override
> +   public NodeMetadata apply(final VMDeployment from) {
> +  final NodeMetadataBuilder builder = new NodeMetadataBuilder();
> +  final Deployment deployment = from.deployment;
> +  builder.id(deployment.name());
> +  builder.providerId(deployment.name());
> +  builder.name(deployment.name());
> +  String group = deployment.name();
> +  int index = group.lastIndexOf("-");

Take care. When using the group naming convention the separator is configurable 
via properties. If you are splitting such generated names, then consider using 
the group naming convention methods to get the group name.

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63967447

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> +   VMSizeToHardware vmSizeToHardware, Map 
> credentialStore) {
> +
> +  this.nodeNamingConvention = namingConvention.createWithoutPrefix();
> +  this.locations = checkNotNull(locations, "locations");
> +  this.imageReferenceToImage = imageReferenceToImage;
> +  this.vmSizeToHardware = vmSizeToHardware;
> +  this.credentialStore = credentialStore;
> +  this.api = api;
> +   }
> +
> +   @Override
> +   public NodeMetadata apply(final VMDeployment from) {
> +  final NodeMetadataBuilder builder = new NodeMetadataBuilder();
> +  final Deployment deployment = from.deployment;
> +  builder.id(deployment.name());
> +  builder.providerId(deployment.name());

This value should be the real "id" in the backend. It looks like the value 
should be `deployment.id()`? 

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63967331

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> +   GroupNamingConvention.Factory namingConvention, 
> ImageReferenceToImage imageReferenceToImage,
> +   VMSizeToHardware vmSizeToHardware, Map 
> credentialStore) {
> +
> +  this.nodeNamingConvention = namingConvention.createWithoutPrefix();
> +  this.locations = checkNotNull(locations, "locations");
> +  this.imageReferenceToImage = imageReferenceToImage;
> +  this.vmSizeToHardware = vmSizeToHardware;
> +  this.credentialStore = credentialStore;
> +  this.api = api;
> +   }
> +
> +   @Override
> +   public NodeMetadata apply(final VMDeployment from) {
> +  final NodeMetadataBuilder builder = new NodeMetadataBuilder();
> +  final Deployment deployment = from.deployment;
> +  builder.id(deployment.name());

This is the "id" jclouds will use as the main id (used to call `getNode`, etc). 
Can this value uniquely identify the node across all locations?

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63967239

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> +
> +   private final ImageReferenceToImage imageReferenceToImage;
> +
> +   private final VMSizeToHardware vmSizeToHardware;
> +
> +   private final Map credentialStore;
> +
> +   @Inject
> +   DeploymentToNodeMetadata(
> +   AzureComputeApi api,
> +   @Memoized Supplier> locations,
> +   GroupNamingConvention.Factory namingConvention, 
> ImageReferenceToImage imageReferenceToImage,
> +   VMSizeToHardware vmSizeToHardware, Map 
> credentialStore) {
> +
> +  this.nodeNamingConvention = namingConvention.createWithoutPrefix();
> +  this.locations = checkNotNull(locations, "locations");

Redundant check. The injector already checks if it is null.

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63967148

Re: [jclouds/jclouds] client credentials JWT support (#952)

[Ignasi Barrera]

Closed #952.

---
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/pull/952#event-666493032

Re: [jclouds/jclouds] client credentials JWT support (#952)

[Ignasi Barrera]

Build failure was unrelated. Merged to master as 
[f46b38dd](http://git-wip-us.apache.org/repos/asf/jclouds/commit/f46b38dd). 
Thanks @jmspring!

---
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/pull/952#issuecomment-220473336

Re: [jclouds/jclouds] Support for "Placement.Tenancy" and "Placement.HostId" AWS EC2 parameters (#954)

[Ignasi Barrera]

Squashed, amended commit message to include the JIRA issue, and pushed to 
master as 
[ccd1ef2b](http://git-wip-us.apache.org/repos/asf/jclouds/commit/ccd1ef2b).Thanks
 @storgashov!

---
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/pull/954#issuecomment-220472400

Re: [jclouds/jclouds] Support for "Placement.Tenancy" and "Placement.HostId" AWS EC2 parameters (#954)

[Ignasi Barrera]

Closed #954.

---
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/pull/954#event-666488147

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> + System.out.println(str);
> +  }
> +  return Iterables.filter(listNodes(), new Predicate() {
> + @Override
> + public boolean apply(final VMDeployment input) {
> +return Iterables.contains(ids, input.deployment.name());
> + }
> +  });
> +   }
> +
> +   private String getGroupId() {
> +  String group =  System.getProperty("test.azurecompute-arm.groupname");
> +  if (group == null)
> + group = "jCloudsGroup";
> +  return group;
> +   }

This method must be removed.

How is this supposed to work? Will users have to configure a resource group 
when creating the context and that one is going to be the only one considered 
by the compute service? Or should instead the compute service be available to 
list nodes in all resource groups?

Would it make sense to use the jclouds "group" to create a resource group?



---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63966048

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> +  List vmDeployments = new ArrayList();
> +
> +  for (Deployment d : deployments){
> + VMDeployment vmDeployment = new VMDeployment();
> + vmDeployment.deployment = d;
> + vmDeployment.vm = 
> api.getVirtualMachineApi(getGroupId()).getInstanceDetails(d.name());
> + List list = getIPAddresses(d);
> + vmDeployment.ipAddressList = list;
> + vmDeployments.add(vmDeployment);
> +  }
> +  return vmDeployments;
> +   }
> +
> +   @Override
> +   public Iterable listNodesByIds(final Iterable ids) {
> +  System.out.println("listNodesByIds");

Remove

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63965857

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> + list.add(ip);
> +  }
> +   }
> +}
> + }
> +  }
> +  return list;
> +   }
> +
> +   @Override
> +   public Iterable listNodes() {
> +  System.out.println("listNodes");
> +
> +  List deployments = 
> api.getDeploymentApi(getGroupId()).list();
> +
> +  System.out.println("Found " + deployments.size() + " nodes");

Remove

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63965817

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> +   for (int e = 0; e < dependsOn.size(); e++) {
> +  if 
> (dependsOn.get(e).resourceType().equals("Microsoft.Network/publicIPAddresses"))
>  {
> + String resourceName = dependsOn.get(e).resourceName();
> + PublicIPAddress ip = 
> api.getPublicIPAddressApi(resourceGroup).get(resourceName);
> + list.add(ip);
> +  }
> +   }
> +}
> + }
> +  }
> +  return list;
> +   }
> +
> +   @Override
> +   public Iterable listNodes() {
> +  System.out.println("listNodes");

Remove this

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63965784

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> + if (jobDone) {
> +// Delete storage account
> +
> api.getStorageAccountApi(getGroupId()).delete(storageAccountName);
> +
> +// Delete NIC
> +uri = api.getNetworkInterfaceCardApi(getGroupId()).delete(id + 
> "nic");
> +if (uri != null){
> +   jobDone = Predicates2.retry(new Predicate() {
> +  @Override public boolean apply(URI uri) {
> + return ParseJobStatus.JobStatus.DONE == 
> api.getJobApi().jobStatus(uri)
> + || ParseJobStatus.JobStatus.NO_CONTENT == 
> api.getJobApi().jobStatus(uri);
> +  }
> +   }, 60 * 10 * 1000 /* 5 minute timeout */).apply(uri);
> +   if (jobDone) {
> +  // Delete public ip
> +  api.getPublicIPAddressApi(getGroupId()).delete(id + 
> "publicip");

Does it make sense to do a "best effort delete" and try to delete the 
deployment and network even if this call fails?

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63965750

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> +
> +   @Override
> +   public void destroyNode(final String id) {
> +  logger.debug("Destroying %s ...", id);
> +  String storageAccountName = id.replaceAll("[^A-Za-z0-9 ]", "") + 
> "storage";
> +  int index = id.lastIndexOf("-");
> +  String group = id.substring(0, index);
> +
> +  // Delete VM
> +  URI uri = api.getVirtualMachineApi(getGroupId()).delete(id);
> +  if (uri != null){
> + boolean jobDone = Predicates2.retry(new Predicate() {
> +@Override public boolean apply(URI uri) {
> +   return ParseJobStatus.JobStatus.DONE == 
> api.getJobApi().jobStatus(uri);
> +}
> + }, 60 * 10 * 1000 /* 5 minute timeout */).apply(uri);

Consider declaring all these predicates in the compute service module so they 
can be easily reused. Also that will facilitate making the timeouts 
configurable (they should be). Have a look at the DigitalOcean compute service 
context module to see an example of how reusable predicates are defined and 
injected.

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63965622

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> +   }
> +
> +   @Override
> +   public ImageReference getImage(final String id) {
> +  Iterable images = listImages();
> +  for (ImageReference image : images) {
> + if (id.contains(image.offer()) && id.contains(image.sku())) {
> +return image;
> + }
> +  }
> +  return null;
> +   }
> +
> +   private String getLocation() {
> +  return "eastasia"; // TODO: get location
> +   }

Remove this :)

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63965349

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> + }
> +  }
> +   }
> +
> +   @Override
> +   public Iterable listImages() {
> +  final List osImages = Lists.newArrayList();
> +  getImagesFromPublisher("Microsoft.WindowsAzure.Compute", osImages);
> +  getImagesFromPublisher("MicrosoftWindowsServer", osImages);
> +  getImagesFromPublisher("Canonical", osImages);
> +  return osImages;
> +   }
> +
> +   @Override
> +   public ImageReference getImage(final String id) {
> +  Iterable images = listImages();

Listing images is often an expensive operation. Isn't there an api to get a 
single image?

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63965315

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> +  OSImageApi osImageApi = api.getOSImageApi(getLocation());
> +  Iterable offerList = osImageApi.listOffers(publisherName);
> +  for (Offer offer : offerList) {
> + Iterable skuList = osImageApi.listSKUs(publisherName, 
> offer.name());
> + for (SKU sku : skuList) {
> +osImagesRef.add(ImageReference.create(publisherName, 
> offer.name(), sku.name(), null));
> + }
> +  }
> +   }
> +
> +   @Override
> +   public Iterable listImages() {
> +  final List osImages = Lists.newArrayList();
> +  getImagesFromPublisher("Microsoft.WindowsAzure.Compute", osImages);
> +  getImagesFromPublisher("MicrosoftWindowsServer", osImages);
> +  getImagesFromPublisher("Canonical", osImages);

It should be better to provide a property with the comma separated values of 
publishers. The api metadata should set the default value to these three 
elements, but this way we allow users to customize the list of publishers they 
want to use, when creating the context.

The same contract for locations applies here. After being transformed by the 
transformation function, global images must not have the location set, and 
images that only exist in a particular location must inform it.

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63965264

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> + name, azureComputeConstants.operationTimeout());
> + logger.warn(illegalStateExceptionMessage);
> +
> + throw new IllegalStateException(illegalStateExceptionMessage);
> +  }
> +
> +  final VMDeployment deployment = deployments.iterator().next();
> +
> +
> +  return new NodeAndInitialCredentials(deployment, name,
> +  
> LoginCredentials.builder().user(loginUser).identity(loginUser).password(loginPassword).authenticateSudo(true).build());
> +   }
> +
> +   @Override
> +   public Iterable listHardwareProfiles() {
> +  return api.getVMSizeApi(getLocation()).list();

This must return the hardware profiles for *all* locations, and how it works 
must be coded in conjunction with the function that transforms the returned 
elements into a jclouds `Hardware`

* If a hardawre profile does not exist in all locations, then when transforming 
it, the `location` field must be set.
* if a hardware profile is global and exists in all locations, then when 
transforming it, the `location` field must be left null.

Take this into account so you return here something that gives the 
transformation function enough context to implement this contract. You can 
create just an intermediate object here and use it to represent hardware 
profiles. This object does not have to be an Azure API object, but any object 
that is convenient; it will never be exposed to users.

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63965010

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> +}
> +return !deployments.isEmpty();
> + }
> +  }, azureComputeConstants.operationTimeout(), 1, SECONDS).apply(name)) {
> + final String illegalStateExceptionMessage = format("Deployment %s 
> was not created within %sms so it will be destroyed.",
> + name, azureComputeConstants.operationTimeout());
> + logger.warn(illegalStateExceptionMessage);
> +
> + throw new IllegalStateException(illegalStateExceptionMessage);
> +  }
> +
> +  final VMDeployment deployment = deployments.iterator().next();
> +
> +
> +  return new NodeAndInitialCredentials(deployment, name,
> +  
> LoginCredentials.builder().user(loginUser).identity(loginUser).password(loginPassword).authenticateSudo(true).build());

Also, authenticate sudo should be configured based on the value it has 
configured in the template options?

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63964676

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> +}
> +return !deployments.isEmpty();
> + }
> +  }, azureComputeConstants.operationTimeout(), 1, SECONDS).apply(name)) {
> + final String illegalStateExceptionMessage = format("Deployment %s 
> was not created within %sms so it will be destroyed.",
> + name, azureComputeConstants.operationTimeout());
> + logger.warn(illegalStateExceptionMessage);
> +
> + throw new IllegalStateException(illegalStateExceptionMessage);
> +  }
> +
> +  final VMDeployment deployment = deployments.iterator().next();
> +
> +
> +  return new NodeAndInitialCredentials(deployment, name,
> +  
> LoginCredentials.builder().user(loginUser).identity(loginUser).password(loginPassword).authenticateSudo(true).build());

Does azure support users configuring the login (via the jclouds template 
options) with SSH keys?

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63964631

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> +}
> +
> +Deployment deployment = 
> api.getDeploymentApi(resourceGroupName).create(name, deploymentTemplate);
> +
> +if (deployment != null) {
> +   VMDeployment vmDeployment = new VMDeployment();
> +   vmDeployment.deployment = deployment;
> +   deployments.add(vmDeployment);
> +} else {
> +   logger.debug("Failed to create deployment!");
> +}
> +return !deployments.isEmpty();
> + }
> +  }, azureComputeConstants.operationTimeout(), 1, SECONDS).apply(name)) {
> + final String illegalStateExceptionMessage = format("Deployment %s 
> was not created within %sms so it will be destroyed.",
> + name, azureComputeConstants.operationTimeout());

This should be using the [common compute service "node running" 
timeout](https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/reference/ComputeServiceConstants.java#L99-L101).
 You can inject the timeouts class here to access the different timeouts.

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63964543

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> +  final String deploymentTemplate = 
> UrlEscapers.urlFormParameterEscaper().escape(json.toJson(properties));
> +
> +  logger.debug("Deployment created with name: %s", name);
> +
> +  final Set deployments = Sets.newHashSet();
> +  if (!retry(new Predicate() {
> + @Override
> + public boolean apply(final String name) {
> +runningNumber++;
> +
> +
> +ResourceGroupApi resourceGroupApi = api.getResourceGroupApi();
> +ResourceGroup resourceGroup = resourceGroupApi.get(getGroupId());
> +String resourceGroupName;
> +
> +if (resourceGroup == null){

Race conditions may appear here! When calling 
`computeService.createNodesInGroup` to create more than one node, jclouds will 
call this method concurrently.
If you need to perform some operations that affect *all* nodes being deployed, 
and perform them just once (such as creating a group, creating the networks or 
security groups indicated in the options, etc), then the right approach is to 
override the `CreateNodesInGroupThenAddToSet` strategy to do that. Take the 
[DigitalOcean 
one](https://github.com/jclouds/jclouds/blob/master/providers/digitalocean2/src/main/java/org/jclouds/digitalocean2/compute/config/DigitalOcean2ComputeServiceContextModule.java#L92)
 as an example. That strategy is invoked only once, just before spawning N 
threads to create the nodes concurrently.

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63964298

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> +  Gson gson = new GsonBuilder().disableHtmlEscaping().create();
> +  org.jclouds.json.Json json = new GsonWrapper(gson);
> +
> +  final String deploymentTemplate = 
> UrlEscapers.urlFormParameterEscaper().escape(json.toJson(properties));
> +
> +  logger.debug("Deployment created with name: %s", name);
> +
> +  final Set deployments = Sets.newHashSet();
> +  if (!retry(new Predicate() {
> + @Override
> + public boolean apply(final String name) {
> +runningNumber++;
> +
> +
> +ResourceGroupApi resourceGroupApi = api.getResourceGroupApi();
> +ResourceGroup resourceGroup = resourceGroupApi.get(getGroupId());

The group id and the api class could be assigned outside the predicate, to 
compute them only once.

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63964025

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Ignasi Barrera]

> +import org.jclouds.domain.LoginCredentials;
> +import org.jclouds.json.internal.GsonWrapper;
> +import org.jclouds.logging.Logger;
> +
> +import com.google.common.base.Predicate;
> +import com.google.common.collect.Iterables;
> +import com.google.common.collect.Lists;
> +import com.google.common.collect.Sets;
> +import org.jclouds.util.Predicates2;
> +
> +/**
> + * Defines the connection between the {@link AzureComputeApi} implementation 
> and the jclouds
> + * {@link org.jclouds.compute.ComputeService}.
> + */
> +@Singleton
> +public class AzureComputeServiceAdapter implements 
> ComputeServiceAdapter {

This should extend the `BaseComputeService` instead of directly implement the 
interface. That base class performs many needed operations such as maintaining 
the credential store, polling the status of nodes, and much more.

---
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/267/files/bae5d6dfcdb26e31057db4551c599683a31b#r63963424

[jira] [Updated] (JCLOUDS-1114) Support AWS EC2 "Placement.Tenancy" and "Placement.HostId" parameters for the "RunInstances" action

[Ignasi Barrera (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ignasi Barrera updated JCLOUDS-1114:

Labels: aws-ec2  (was: )

> Support AWS EC2 "Placement.Tenancy" and "Placement.HostId" parameters for the 
> "RunInstances" action
> ---
>
> Key: JCLOUDS-1114
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1114
> Project: jclouds
>  Issue Type: Improvement
>  Components: jclouds-compute
>Affects Versions: 1.7.3, 1.8.1, 1.9.2
>Reporter: Sergey Torgashov
>  Labels: aws-ec2
> Fix For: 2.0.0
>
>
> The AWS EC2 API has the "RunInstances" action which includes the "Placement" 
> parameter. The latter contains, inter alia, the "Tenancy" and "HostId" fields 
> which allow to define a tenancy of the launching instance and ID of the 
> dedicted host on which the instance should reside.
> These parameters aren't currently supported.
> See also:
> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html
> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Placement.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (JCLOUDS-1114) Support AWS EC2 "Placement.Tenancy" and "Placement.HostId" parameters for the "RunInstances" action

[Ignasi Barrera (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ignasi Barrera resolved JCLOUDS-1114.
-
   Resolution: Fixed
Fix Version/s: 2.0.0

> Support AWS EC2 "Placement.Tenancy" and "Placement.HostId" parameters for the 
> "RunInstances" action
> ---
>
> Key: JCLOUDS-1114
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1114
> Project: jclouds
>  Issue Type: Improvement
>  Components: jclouds-compute
>Affects Versions: 1.7.3, 1.8.1, 1.9.2
>Reporter: Sergey Torgashov
>  Labels: aws-ec2
> Fix For: 2.0.0
>
>
> The AWS EC2 API has the "RunInstances" action which includes the "Placement" 
> parameter. The latter contains, inter alia, the "Tenancy" and "HostId" fields 
> which allow to define a tenancy of the launching instance and ID of the 
> dedicted host on which the instance should reside.
> These parameters aren't currently supported.
> See also:
> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html
> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Placement.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCLOUDS-1114) Support AWS EC2 "Placement.Tenancy" and "Placement.HostId" parameters for the "RunInstances" action

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on JCLOUDS-1114:
--

Commit ccd1ef2b4da33e6d4daa7fd38779388cabf61009 in jclouds's branch 
refs/heads/master from [~satorg]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=ccd1ef2 ]

JCLOUDS-1114: Adding support for "Placement.Tenancy" and "Placement.HostId" AWS 
EC2 parameters


> Support AWS EC2 "Placement.Tenancy" and "Placement.HostId" parameters for the 
> "RunInstances" action
> ---
>
> Key: JCLOUDS-1114
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1114
> Project: jclouds
>  Issue Type: Improvement
>  Components: jclouds-compute
>Affects Versions: 1.7.3, 1.8.1, 1.9.2
>Reporter: Sergey Torgashov
>
> The AWS EC2 API has the "RunInstances" action which includes the "Placement" 
> parameter. The latter contains, inter alia, the "Tenancy" and "HostId" fields 
> which allow to define a tenancy of the launching instance and ID of the 
> dedicted host on which the instance should reside.
> These parameters aren't currently supported.
> See also:
> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html
> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Placement.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [jclouds/jclouds-labs] JCLOUDS-664 Azurecompute-arm DeploymentApi OSImageApi VMSizeApi Bindings (#267)

[Rita Zhang]

_bump_ @nacx We have folks who are waiting to test this in few days. Would be 
awesome if we could get this merged soon since we have couple of more PRs left. 
Thank you so much for all your feedback!!!

---
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/267#issuecomment-220456609

Jenkins build is back to normal : jclouds-guava-guice-compat » 19.0-rc1,4.0,OpenJDK 7 (latest) #151

[jenkins-no-reply]

See 

Re: [jclouds/jclouds] client credentials JWT support (#952)

[Jim Spring]

@nacx -- all edits should be in place.  local build completing successfully.  
Will check PR build in a bit.

---
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/pull/952#issuecomment-220393228

Re: [jclouds/jclouds] Support for "Placement.Tenancy" and "Placement.HostId" AWS EC2 parameters (#954)

[Sergey Torgashov]

@nacx, thanks for your review! I've updated the patch according to your 
comments, please take a look.
Also please confirm, if the ``Tenancy`` enum name and package I've selected is 
ok.

---
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/pull/954#issuecomment-220390856

Re: [jclouds/jclouds] Fix cleanup when the security group extension is not available. (#955)

[Zack Shoylev]

Closed #955.

---
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/pull/955#event-666104027

Re: [jclouds/jclouds] Fix cleanup when the security group extension is not available. (#955)

[Zack Shoylev]

merged

---
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/pull/955#issuecomment-220390129

Re: [jclouds/jclouds-labs] JCLOUDS-1041: Fix NPE when deserializing Port in Docker 1.9.1 (#269)

[Andrea Turli]

Lgtm

---
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/269#issuecomment-220382602

Re: [jclouds/jclouds-labs] JCLOUDS-1041: Fix NPE when deserializing Port in Docker 1.9.1 (#269)

[Andrea Turli]

rebuild please

---
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/269#issuecomment-220373462

Re: [jclouds/jclouds-labs] JCLOUDS-1041: Fix NPE when deserializing Port in Docker 1.9.1 (#269)

[Duncan Grant]

rebuild please

---
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/269#issuecomment-220351986

Re: [jclouds/jclouds-labs] JCLOUDS-1041: Fix NPE when deserializing Port in Docker 1.9.1 (#269)

[Andrea Turli]

rebuild please

---
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/269#issuecomment-220332247

Re: [jclouds/jclouds] JCLOUDS-1044 fix handling NULL JsonTokens in adapters under NullFilte… (#958)

[Andrea Turli]

Closed #958.

---
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/pull/958#event-665833402

Re: [jclouds/jclouds] JCLOUDS-1044 fix handling NULL JsonTokens in adapters under NullFilte… (#958)

[Andrea Turli]

Merged at 
[1.9.x](http://git-wip-us.apache.org/repos/asf/jclouds/commit/7016b040)

---
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/pull/958#issuecomment-220332030

Re: [jclouds/jclouds] JCLOUDS-1044 fix handling NULL JsonTokens in adapters under NullFilte… (#958)

[Andrea Turli]

thanks @duncangrant 

---
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/pull/958#issuecomment-220332124

Re: [jclouds/jclouds] JCLOUDS-1044 fix handling NULL JsonTokens in adapters under NullFilte… (#958)

[Andrea Turli]

ok build is happy, merging now

---
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/pull/958#issuecomment-220331954

[jira] [Commented] (JCLOUDS-1044) MapTypeAdapter and IterableTypeAdapter doesn't handle NULL values correctly

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on JCLOUDS-1044:
--

Commit 7016b040d79e671b41dac06f877a54139ad4def7 in jclouds's branch 
refs/heads/1.9.x from [~kwart]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=7016b04 ]

JCLOUDS-1044 fix handling NULL JsonTokens in adapters under 
NullFilteringTypeAdapterFactories class


> MapTypeAdapter and IterableTypeAdapter doesn't handle NULL values correctly
> ---
>
> Key: JCLOUDS-1044
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1044
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-core
>Affects Versions: 1.9.1, 2.0.0
>Reporter: Josef Cacek
>Priority: Critical
> Fix For: 2.0.0
>
>
> JSON deserialization fails for {{null}} values in "inner collections/maps". 
> The adapters in {{NullFilteringTypeAdapterFactories}} are missing check for 
> *{{JsonToken.NULL}}*
> Sample Java type, which can hit the problem:
> {code}
> Map>>
> {code}
> and JSON to reproduce the issue:
> {code}
> {"value":[null]}
> {code}
> or another one:
> {code}
> {"value":null}
> {code}
> The stacktrace then can look like:
> {code}
> 21:50:57.824 [main] ERROR org.jclouds.http.functions.ParseJson - Error 
> parsing input: java.lang.IllegalStateException: Expected BEGIN_ARRAY but was 
> NULL at line 1 column 3791 path $.NetworkSettings.Ports.
> com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: 
> Expected BEGIN_ARRAY but was NULL at line 1 column 3791 path 
> $.NetworkSettings.Ports.
>   at 
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.read(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:190)
>  ~[jclouds-core-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
>   at 
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$ParameterReader.read(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:272)
>  ~[jclouds-core-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
>   at 
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.read(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:184)
>  ~[jclouds-core-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
>   at com.google.gson.Gson.fromJson(Gson.java:810) ~[gson-2.3.1.jar:na]
>   at com.google.gson.Gson.fromJson(Gson.java:775) ~[gson-2.3.1.jar:na]
>   at com.google.gson.Gson.fromJson(Gson.java:724) ~[gson-2.3.1.jar:na]
>   at org.jclouds.json.internal.GsonWrapper.fromJson(GsonWrapper.java:42) 
> ~[jclouds-core-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
>   at org.jclouds.http.functions.ParseJson.apply(ParseJson.java:83) 
> [jclouds-core-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
>   at org.jclouds.http.functions.ParseJson.apply(ParseJson.java:77) 
> [jclouds-core-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
>   at org.jclouds.http.functions.ParseJson.apply(ParseJson.java:62) 
> [jclouds-core-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
>   at org.jclouds.http.functions.ParseJson.apply(ParseJson.java:42) 
> [jclouds-core-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
>   at 
> org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:90) 
> [jclouds-core-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
>   at 
> org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:73) 
> [jclouds-core-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
>   at 
> org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:44) 
> [jclouds-core-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
>   at 
> org.jclouds.reflect.FunctionalReflection$FunctionalInvocationHandler.handleInvocation(FunctionalReflection.java:117)
>  [jclouds-core-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
>   at 
> com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:87)
>  [guava-18.0.jar:na]
>   at com.sun.proxy.$Proxy77.inspectContainer(Unknown Source) [na:na]
>   at 
> org.jclouds.docker.compute.strategy.DockerComputeServiceAdapter.listNodes(DockerComputeServiceAdapter.java:214)
>  [docker-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
>   at 
> org.jclouds.compute.strategy.impl.AdaptingComputeServiceStrategies.listDetailsOnNodesMatching(AdaptingComputeServiceStrategies.java:122)
>  [jclouds-compute-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
>   at 
> org.jclouds.compute.strategy.impl.AdaptingComputeServiceStrategies.listNodes(AdaptingComputeServiceStrategies.java:112)
>  [jclouds-compute-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
>   at 
> org.jclouds.compute.strategy.impl.CreateNodesWithGroupEncodedIntoNameThenAddToSet.getNextNames(CreateNodes

[jclouds/jclouds-labs] JCLOUDS-1041: Fix NPE when deserializing Port in Docker 1.9.1 (#269)

[Duncan Grant]

This backports this change (46aec3aa2bdb362d7ba9a17cb1c3c9b0509b30ef) from 
2.0.0 to 1.9.x.  Needed to fix issue where ip is null in json returned from 
Docker REST API.
You can view, comment on, or merge this pull request online at:

  https://github.com/jclouds/jclouds-labs/pull/269

-- Commit Summary --

  * JCLOUDS-1041: Fix NPE when deserializing Port in Docker 1.9.1

-- File Changes --

M docker/src/main/java/org/jclouds/docker/domain/Port.java (7)
M docker/src/test/java/org/jclouds/docker/parse/ContainersParseTest.java 
(16)
M docker/src/test/resources/containers.json (16)

-- Patch Links --

https://github.com/jclouds/jclouds-labs/pull/269.patch
https://github.com/jclouds/jclouds-labs/pull/269.diff

---
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/269

Re: [jclouds/jclouds] JCLOUDS-1044 fix handling NULL JsonTokens in adapters under NullFilte… (#958)

[Andrea Turli]

Sorry @grkvlt I've been notified just now about this PR by github, looks like 
@nacx already reviewed it: thanks @nacx !

---
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/pull/958#issuecomment-220329463

Re: [jclouds/jclouds] JCLOUDS-1044 fix handling NULL JsonTokens in adapters under NullFilte… (#958)

[Duncan Grant]

@nacx 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/pull/958#issuecomment-220327819

Re: [jclouds/jclouds] Fix cleanup when the security group extension is not available. (#955)

[Ignasi Barrera]

+1!

---
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/pull/955#issuecomment-220293929

Re: [jclouds/jclouds] update CloudstackTemplateOptions pattern (#957)

[Ignasi Barrera]

> }
>  
> -   public CloudStackTemplateOptions setupStaticNat(boolean setupStaticNat) {
> -  this.setupStaticNat = setupStaticNat;
> +   public CloudStackTemplateOptions userData(URL userDataUrl) throws 
> IOException {
> +  this.userData = Resources.toString(checkNotNull(userDataUrl, 
> "userDataUrl"), Charsets.UTF_8).getBytes(Charsets.UTF_8);

Why providing this method that accepts a URL? I don't see it necessary and only 
introduces issues: can we guarantee the classloader being used to load the 
resource the right one to load the file? And if jclouds code is deployed in a 
webapp? Where do we expect to load files from?

IMO there is no need to provide this "sugar" method. Let users read 
files/resources themselves and just pass the array of bytes.

---
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/pull/957/files/e808dc64d204b994b579a7a1d626da728656cc2f#r63859521

Re: [jclouds/jclouds] JCLOUDS-1044 fix handling NULL JsonTokens in adapters under NullFilte… (#958)

[Ignasi Barrera]

LGTM! Let's merge it once the build finishes and is green. Thanks @duncangrant 
@grkvlt!

---
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/pull/958#issuecomment-220291027

Re: [jclouds/jclouds] JCLOUDS-1044 fix handling NULL JsonTokens in adapters under NullFilte… (#958)

[Andrew Donald Kennedy]

@andreaturli Can you take a look, please? We need this for the jclouds-labs 
Docker provider, to fix behaviour where JSON maps returned by the Docker REST 
API have entries with null values, instead of empty lists.

---
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/pull/958#issuecomment-220289715

[jclouds/jclouds] JCLOUDS-1044 fix handling NULL JsonTokens in adapters under NullFilte… (#958)

[Duncan Grant]

…ringTypeAdapterFactories class

This PR backports this fix (0fb1b459a607f21f6a8ebd7492879d02553c4b88) from 
2.0.0 to 1.9.x.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * JCLOUDS-1044 fix handling NULL JsonTokens in adapters under 
NullFilteringTypeAdapterFactories class

-- File Changes --

M apis/chef/src/main/java/org/jclouds/chef/config/ChefParserModule.java (59)
M apis/chef/src/test/java/org/jclouds/chef/config/ChefParserModuleTest.java 
(24)
M 
core/src/main/java/org/jclouds/json/internal/NullFilteringTypeAdapterFactories.java
 (11)
M 
core/src/test/java/org/jclouds/json/internal/NullFilteringTypeAdapterFactoriesTest.java
 (21)

-- Patch Links --

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

---
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/pull/958

[jclouds/jclouds] update CloudstackTemplateOptions pattern (#957)

[Andrea Turli]

You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * update CloudstackTemplateOptions pattern

-- File Changes --

M 
apis/cloudstack/src/main/java/org/jclouds/cloudstack/compute/options/CloudStackTemplateOptions.java
 (523)
M 
apis/cloudstack/src/main/java/org/jclouds/cloudstack/compute/strategy/CloudStackComputeServiceAdapter.java
 (3)
M 
apis/cloudstack/src/test/java/org/jclouds/cloudstack/compute/options/CloudStackTemplateOptionsTest.java
 (60)
M 
apis/cloudstack/src/test/java/org/jclouds/cloudstack/compute/strategy/OptionsConverterTest.java
 (26)

-- Patch Links --

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

---
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/pull/957

[jclouds/jclouds] update CloudstackTemplateOptions pattern (#956)

[Andrea Turli]

You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * update CloudstackTemplateOptions pattern

-- File Changes --

M 
apis/cloudstack/src/main/java/org/jclouds/cloudstack/compute/options/CloudStackTemplateOptions.java
 (522)
M 
apis/cloudstack/src/main/java/org/jclouds/cloudstack/compute/strategy/CloudStackComputeServiceAdapter.java
 (3)
M 
apis/cloudstack/src/test/java/org/jclouds/cloudstack/compute/options/CloudStackTemplateOptionsTest.java
 (60)
M 
apis/cloudstack/src/test/java/org/jclouds/cloudstack/compute/strategy/OptionsConverterTest.java
 (26)

-- Patch Links --

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

---
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/pull/956