Re: [jclouds-labs] JCLOUDS-702: JClouds ProfitBricks provider - ComputeServiceAdapter (#145)
[Live test results.](https://gist.github.com/devcsrj/828e5be44a54f5217cbd/088324b581f7f528144fc43d2c42cb1f529d60fb) `Tests run: 25, Failures: 5, Errors: 0, Skipped: 11` Weirdly enough, when doing debug mode (adding `-Dmaven.surefire.debug` and breakpoint at [testGet](https://github.com/jclouds/jclouds/blob/master/compute/src/test/java/org/jclouds/compute/internal/BaseComputeServiceLiveTest.java#L521)) the test doesn't stop, as opposed from previous comment.) As it turns out, it's not possible to concurrently execute methods in a datacenter. (i.e.: when using `client.rebootNodesMatching(..)`, other nodes would actually fail to receive the request because the API complains that a `PROVISIONING_IN_PROCESS`.) Need to refactor `ProfitBricksComputeServiceAdapter` to use a single-thread worker per datacenter approach. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/145#issuecomment-103782440
Re: [jclouds] add aws s3 signature v4 (#678)
I thought about the content-length again. The old V2 implementation wasn't able to handle unknown content-lengths. So does the V4. But I think it wouldn't be so difficult to add this. Because chunking is already implemented nicely and instead of sending the content-length of the complete payload, one could switch to transfer-encoding instead - like Noted here: http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-streaming.html That would mean: Transfer-Encoding: chunked should do the trick and so omitting Content-Length completely. That would be really nice, since in our project we aren't always be able to get the complete content length in advance (live streaming from browser clients etc.). So in the worst-case, we have temporarily store the whole stream to disk (to get the content length) before we can send it to s3. What do you guys think? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/678#issuecomment-103791927
[jira] [Updated] (JCLOUDS-861) node creation fails due to ssh failure
[
https://issues.apache.org/jira/browse/JCLOUDS-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignasi Barrera updated JCLOUDS-861:
---
Labels: google-compute-engine (was: )
node creation fails due to ssh failure
--
Key: JCLOUDS-861
URL: https://issues.apache.org/jira/browse/JCLOUDS-861
Project: jclouds
Issue Type: Bug
Components: jclouds-labs-google
Reporter: Yaron Rosenbaum
Priority: Blocker
Labels: google-compute-engine
I am creating CoreOS nodes, and using cloud-init with them. The cloud-init
takes a while to process.
11:42:32.780 [user thread 3] ERROR jclouds.ssh -
(core:rsa[ssh-agent]@1….2) error acquiring {hostAndPort=1…2:22,
loginUser=core, ssh=null, connectTimeout=6, sessionTimeout=6} (not
retryable): Exhausted available authentication methods
net.schmizz.sshj.userauth.UserAuthException: Exhausted available
authentication methods
I’ve set the following overrides:
overrides.setProperty(ComputeServiceProperties.POLL_INITIAL_PERIOD,
TWENTY_SECONDS);
overrides.setProperty(ComputeServiceProperties.POLL_MAX_PERIOD,
TWENTY_SECONDS);
// 18 retries of 15 seconds -- 4.5 min
overrides.setProperty(Constants.PROPERTY_MAX_RETRIES, 6);
overrides.setProperty(Constants.PROPERTY_RETRY_DELAY_START, 15);
These overrides had no effect.
overrides.setProperty(jclouds.ssh.max-retries, 100);
overrides.setProperty(jclouds.ssh.retry-auth, true);
These overrides worked - ssh retries for 100 times, but: the sleep time
between retries is 2s (which should be exponential backoff, and configurable)
and - eventually locks down the ssh agent for too many retries
(the ssh agent is up, it's only that the ssh key was not installed yet...)
My workaround is to install ssh keys as part of cloud-init, and then
everything works ok, but this is a serious bug, and this workaround will not
work in all cases.
This MAY be related to:
https://github.com/jclouds/jclouds-labs-google/pull/118
PS.
I setup cloud-init by setting user metadata “user-data”=the content of the
cloud-init.yaml file.
cloud-init works, node IS accessible via ssh, and my unit files are up and
running.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [jclouds-labs] JCLOUDS-702: JClouds ProfitBricks provider - ComputeServiceAdapter (#145)
Interesting. IIRC a similar thing happens in Azure. It is resolved there by using a [ConflictManagementPredicate](https://github.com/jclouds/jclouds-labs/blob/master/azurecompute/src/main/java/org/jclouds/azurecompute/util/ConflictManagementPredicate.java) that tries to complete the operation until it fails or times out. You can see an example usage [here](https://github.com/jclouds/jclouds-labs/blob/master/azurecompute/src/main/java/org/jclouds/azurecompute/compute/AzureComputeServiceAdapter.java#L146-L159). Just a tip! --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/145#issuecomment-103813539
[jira] [Commented] (JCLOUDS-172) Graduate GCE to core
[ https://issues.apache.org/jira/browse/JCLOUDS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14552268#comment-14552268 ] Ignasi Barrera commented on JCLOUDS-172: I've added JCLOUDS-908 as a subtask here. It is important to have it fixed soon. It prevents nodes from being listed if there are already existing nodes or firewall tags that don't follow the jclouds naming conventions. Graduate GCE to core -- Key: JCLOUDS-172 URL: https://issues.apache.org/jira/browse/JCLOUDS-172 Project: jclouds Issue Type: Task Components: jclouds-compute, jclouds-labs-google Affects Versions: 1.8.0 Reporter: Andrew Bayer Assignee: Ignasi Barrera Priority: Critical Labels: google-compute-engine We should really get GCE to a finished state and include it in 1.7.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCLOUDS-908) BaseComputeService#listNodes throwing an exception
[
https://issues.apache.org/jira/browse/JCLOUDS-908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignasi Barrera updated JCLOUDS-908:
---
Issue Type: Sub-task (was: Bug)
Parent: JCLOUDS-172
BaseComputeService#listNodes throwing an exception
--
Key: JCLOUDS-908
URL: https://issues.apache.org/jira/browse/JCLOUDS-908
Project: jclouds
Issue Type: Sub-task
Components: jclouds-compute, jclouds-labs-google
Affects Versions: 1.8.1, 1.9.0
Reporter: Pedro Ribeiro
If I have an instance named j-t2, then when I call
BaseComputeService#listNodes, I get the following error. The 'j' in the
exception seems to result from some manipulation of the instance name.
{code}
Caused by: java.lang.IllegalArgumentException: Object 'j' doesn't match dns
naming constraints. Reason: Can't be null or empty. Length must be 3 to 63
symbols..
at
org.jclouds.predicates.validators.DnsNameValidator.exception(DnsNameValidator.java:74)
at
org.jclouds.predicates.validators.DnsNameValidator.validate(DnsNameValidator.java:51)
at
org.jclouds.predicates.validators.DnsNameValidator.validate(DnsNameValidator.java:36)
at
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.checkGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:124)
at
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.sharedNameForGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:120)
at
org.jclouds.googlecomputeengine.compute.functions.FirewallTagNamingConvention$Factory.get(FirewallTagNamingConvention.java:39)
at
org.jclouds.googlecomputeengine.compute.functions.InstanceInZoneToNodeMetadata.apply(InstanceInZoneToNodeMetadata.java:89)
at
org.jclouds.googlecomputeengine.compute.functions.InstanceInZoneToNodeMetadata.apply(InstanceInZoneToNodeMetadata.java:51)
at
shaded.com.google.common.base.Functions$FunctionComposition.apply(Functions.java:216)
at
shaded.com.google.common.collect.Iterators$8.transform(Iterators.java:799)
at
shaded.com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at
shaded.com.google.common.collect.Iterators$7.computeNext(Iterators.java:651)
at
shaded.com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at
shaded.com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at shaded.com.google.common.collect.Iterators.addAll(Iterators.java:361)
at shaded.com.google.common.collect.Iterables.addAll(Iterables.java:354)
at shaded.com.google.common.collect.Sets.newLinkedHashSet(Sets.java:328)
at
org.jclouds.compute.internal.BaseComputeService.listNodes(BaseComputeService.java:335)
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
com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:40)
at com.sun.proxy.$Proxy107.listNodes(Unknown Source)
at
jenkins.plugins.jclouds.compute.JCloudsCloud.getRunningNodesCount(JCloudsCloud.java:389)
at
jenkins.plugins.jclouds.compute.JCloudsCloud.doProvision(JCloudsCloud.java:372)
... 73 more
{code}
*Note*: I have only tested this with version 1.8.1 and I am calling jclouds
from inside a jenkins plugin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCLOUDS-908) BaseComputeService#listNodes throwing an exception
[
https://issues.apache.org/jira/browse/JCLOUDS-908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignasi Barrera updated JCLOUDS-908:
---
Affects Version/s: 1.9.0
BaseComputeService#listNodes throwing an exception
--
Key: JCLOUDS-908
URL: https://issues.apache.org/jira/browse/JCLOUDS-908
Project: jclouds
Issue Type: Bug
Components: jclouds-compute, jclouds-labs-google
Affects Versions: 1.8.1, 1.9.0
Reporter: Pedro Ribeiro
If I have an instance named j-t2, then when I call
BaseComputeService#listNodes, I get the following error. The 'j' in the
exception seems to result from some manipulation of the instance name.
{code}
Caused by: java.lang.IllegalArgumentException: Object 'j' doesn't match dns
naming constraints. Reason: Can't be null or empty. Length must be 3 to 63
symbols..
at
org.jclouds.predicates.validators.DnsNameValidator.exception(DnsNameValidator.java:74)
at
org.jclouds.predicates.validators.DnsNameValidator.validate(DnsNameValidator.java:51)
at
org.jclouds.predicates.validators.DnsNameValidator.validate(DnsNameValidator.java:36)
at
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.checkGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:124)
at
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.sharedNameForGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:120)
at
org.jclouds.googlecomputeengine.compute.functions.FirewallTagNamingConvention$Factory.get(FirewallTagNamingConvention.java:39)
at
org.jclouds.googlecomputeengine.compute.functions.InstanceInZoneToNodeMetadata.apply(InstanceInZoneToNodeMetadata.java:89)
at
org.jclouds.googlecomputeengine.compute.functions.InstanceInZoneToNodeMetadata.apply(InstanceInZoneToNodeMetadata.java:51)
at
shaded.com.google.common.base.Functions$FunctionComposition.apply(Functions.java:216)
at
shaded.com.google.common.collect.Iterators$8.transform(Iterators.java:799)
at
shaded.com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at
shaded.com.google.common.collect.Iterators$7.computeNext(Iterators.java:651)
at
shaded.com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at
shaded.com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at shaded.com.google.common.collect.Iterators.addAll(Iterators.java:361)
at shaded.com.google.common.collect.Iterables.addAll(Iterables.java:354)
at shaded.com.google.common.collect.Sets.newLinkedHashSet(Sets.java:328)
at
org.jclouds.compute.internal.BaseComputeService.listNodes(BaseComputeService.java:335)
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
com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:40)
at com.sun.proxy.$Proxy107.listNodes(Unknown Source)
at
jenkins.plugins.jclouds.compute.JCloudsCloud.getRunningNodesCount(JCloudsCloud.java:389)
at
jenkins.plugins.jclouds.compute.JCloudsCloud.doProvision(JCloudsCloud.java:372)
... 73 more
{code}
*Note*: I have only tested this with version 1.8.1 and I am calling jclouds
from inside a jenkins plugin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-908) BaseComputeService#listNodes throwing an exception
[
https://issues.apache.org/jira/browse/JCLOUDS-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14552262#comment-14552262
]
Ignasi Barrera commented on JCLOUDS-908:
This seems to also affect the firewall policy naming convention as per:
http://stackoverflow.com/questions/30342993/managing-google-cloud-instances-using-jcloud-api
Even though jclouds uses its own naming when creating instances or firewall
tags, we need to make sure we don't fil when listting them, as there could be
pre-existing objects that don't follow these conventions.
BaseComputeService#listNodes throwing an exception
--
Key: JCLOUDS-908
URL: https://issues.apache.org/jira/browse/JCLOUDS-908
Project: jclouds
Issue Type: Bug
Components: jclouds-compute, jclouds-labs-google
Affects Versions: 1.8.1, 1.9.0
Reporter: Pedro Ribeiro
If I have an instance named j-t2, then when I call
BaseComputeService#listNodes, I get the following error. The 'j' in the
exception seems to result from some manipulation of the instance name.
{code}
Caused by: java.lang.IllegalArgumentException: Object 'j' doesn't match dns
naming constraints. Reason: Can't be null or empty. Length must be 3 to 63
symbols..
at
org.jclouds.predicates.validators.DnsNameValidator.exception(DnsNameValidator.java:74)
at
org.jclouds.predicates.validators.DnsNameValidator.validate(DnsNameValidator.java:51)
at
org.jclouds.predicates.validators.DnsNameValidator.validate(DnsNameValidator.java:36)
at
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.checkGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:124)
at
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.sharedNameForGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:120)
at
org.jclouds.googlecomputeengine.compute.functions.FirewallTagNamingConvention$Factory.get(FirewallTagNamingConvention.java:39)
at
org.jclouds.googlecomputeengine.compute.functions.InstanceInZoneToNodeMetadata.apply(InstanceInZoneToNodeMetadata.java:89)
at
org.jclouds.googlecomputeengine.compute.functions.InstanceInZoneToNodeMetadata.apply(InstanceInZoneToNodeMetadata.java:51)
at
shaded.com.google.common.base.Functions$FunctionComposition.apply(Functions.java:216)
at
shaded.com.google.common.collect.Iterators$8.transform(Iterators.java:799)
at
shaded.com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at
shaded.com.google.common.collect.Iterators$7.computeNext(Iterators.java:651)
at
shaded.com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at
shaded.com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at shaded.com.google.common.collect.Iterators.addAll(Iterators.java:361)
at shaded.com.google.common.collect.Iterables.addAll(Iterables.java:354)
at shaded.com.google.common.collect.Sets.newLinkedHashSet(Sets.java:328)
at
org.jclouds.compute.internal.BaseComputeService.listNodes(BaseComputeService.java:335)
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
com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:40)
at com.sun.proxy.$Proxy107.listNodes(Unknown Source)
at
jenkins.plugins.jclouds.compute.JCloudsCloud.getRunningNodesCount(JCloudsCloud.java:389)
at
jenkins.plugins.jclouds.compute.JCloudsCloud.doProvision(JCloudsCloud.java:372)
... 73 more
{code}
*Note*: I have only tested this with version 1.8.1 and I am calling jclouds
from inside a jenkins plugin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JCLOUDS-909) GCE NullPointer
Tomas Fecko created JCLOUDS-909: --- Summary: GCE NullPointer Key: JCLOUDS-909 URL: https://issues.apache.org/jira/browse/JCLOUDS-909 Project: jclouds Issue Type: Bug Affects Versions: 1.9.0 Reporter: Tomas Fecko After calling destroy on instance, NPE appeared. Instance was started with network, I already created before, for all future instances. java.lang.NullPointerException at org.jclouds.googlecomputeengine.compute.GoogleComputeEngineService.cleanUpNetworksAndFirewallsForGroup(GoogleComputeEngineService.java:138) at org.jclouds.googlecomputeengine.compute.GoogleComputeEngineService.cleanUpIncidentalResourcesOfDeadNodes(GoogleComputeEngineService.java:128) at org.jclouds.compute.internal.BaseComputeService.destroyNodesMatching(BaseComputeService.java:274) at org.librade.comla.components.ComlaServerManagementComponent$8.run(ComlaServerManagementComponent.java:586) at org.fabric3.execution.runtime.PropagatingRunnable.run(PropagatingRunnable.java:33) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) 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:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCLOUDS-909) GCE NullPointer
[ https://issues.apache.org/jira/browse/JCLOUDS-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Fecko updated JCLOUDS-909: Component/s: jclouds-compute Environment: linux Labels: compute gce (was: ) GCE NullPointer --- Key: JCLOUDS-909 URL: https://issues.apache.org/jira/browse/JCLOUDS-909 Project: jclouds Issue Type: Bug Components: jclouds-compute Affects Versions: 1.9.0 Environment: linux Reporter: Tomas Fecko Labels: compute, gce After calling destroy on instance, NPE appeared. Instance was started with network, I already created before, for all future instances. java.lang.NullPointerException at org.jclouds.googlecomputeengine.compute.GoogleComputeEngineService.cleanUpNetworksAndFirewallsForGroup(GoogleComputeEngineService.java:138) at org.jclouds.googlecomputeengine.compute.GoogleComputeEngineService.cleanUpIncidentalResourcesOfDeadNodes(GoogleComputeEngineService.java:128) at org.jclouds.compute.internal.BaseComputeService.destroyNodesMatching(BaseComputeService.java:274) at org.librade.comla.components.ComlaServerManagementComponent$8.run(ComlaServerManagementComponent.java:586) at org.fabric3.execution.runtime.PropagatingRunnable.run(PropagatingRunnable.java:33) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) 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:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCLOUDS-798) getting OutOfMemory while fetching images from aws
[
https://issues.apache.org/jira/browse/JCLOUDS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Gaul resolved JCLOUDS-798.
-
Resolution: Not A Problem
Assignee: Andrew Gaul
getting OutOfMemory while fetching images from aws
--
Key: JCLOUDS-798
URL: https://issues.apache.org/jira/browse/JCLOUDS-798
Project: jclouds
Issue Type: Bug
Components: jclouds-compute, jclouds-core
Affects Versions: 1.7.3
Environment: jdk 1.7, windows 7
Reporter: Subhadip
Assignee: Andrew Gaul
Hi,
While fetching the selfImages from aws suddenly I'm started getting OOM
error. below is my code to fetch images. Please help to resolve the issue.
{code:language=java}
try {
ComputeServiceContext computeServiceContext =
getComputeContext(cloudType);
ComputeService computeService = computeServiceContext
.getComputeService();
if (null != computeService null !=
computeService.listImages()) {
for (Image image : computeService.listImages())
{
templateBean = new TemplateBean();
templateBean.setImageId(image.getId());
templateBean.setTemplateName(image.getName());
templateBean.setCloudType(cloudType);
if
(Constants.AWS_EC2.equalsIgnoreCase(cloudType)) {
templateBean.setZoneId(AP_SOUTHEAST_1);
}
list.add(templateBean);
}
imageList = new TemplatesBean();
imageList.setName(cloudType);
imageList.setImages(list);
templateStatusBean.setTemplatesBean(imageList);
} else {
errorBean
.setErrorCode(ErrorCode.COMPUTE_SERVICE.getErrorCode());
errorBean.setErrorMessage(ErrorCode.COMPUTE_SERVICE
.getMessage());
templateStatusBean.setErrorBean(errorBean);
}
} catch (Exception exception) {
LOG.warn(exception, exception);
errorBean.setErrorCode(ErrorCode.SELF_IMAGE_ISSUE.getErrorCode());
errorBean.setErrorMessage(ErrorCode.SELF_IMAGE_ISSUE.getMessage()
+ : + exception.getMessage());
templateStatusBean.setErrorBean(errorBean);
}
return templateStatusBean;
}
{code}
I'm getting the below exceptions in apache tomcat... saying the rest call for
http connection of jclouds is failing.
{noformat}
SEVERE: Servlet.service() for servlet [spring] in context with path
[/aricloud] threw exception [Handler processing failed; nested exception is
com.google.common.util.concurrent.ExecutionError:
com.google.common.util.concurrent.ExecutionError:
com.google.common.util.concurrent.ExecutionError: java.lang.OutOfMemoryError:
unable to create new native thread] with root cause
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:640)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1188)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1215)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1199)
at
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
at
sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1031)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:230)
at
org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.writePayloadToConnection(JavaUrlHttpCommandExecutorService.java:305)
at
org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.convert(JavaUrlHttpCommandExecutorService.java:192)
at
[jira] [Comment Edited] (JCLOUDS-908) BaseComputeService#listNodes throwing an exception
[
https://issues.apache.org/jira/browse/JCLOUDS-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14553002#comment-14553002
]
Daniel Broudy edited comment on JCLOUDS-908 at 5/20/15 7:59 PM:
I am assuming we want to display all instances when
BaseComputeService#listNodes is called.
was (Author: broudy):
Do we want to filter out instances that do not match the naming convention when
we do BaseComputeService#listNodes like we do with firewall tags or do we want
to display all instances?
BaseComputeService#listNodes throwing an exception
--
Key: JCLOUDS-908
URL: https://issues.apache.org/jira/browse/JCLOUDS-908
Project: jclouds
Issue Type: Sub-task
Components: jclouds-compute, jclouds-labs-google
Affects Versions: 1.8.1, 1.9.0
Reporter: Pedro Ribeiro
If I have an instance named j-t2, then when I call
BaseComputeService#listNodes, I get the following error. The 'j' in the
exception seems to result from some manipulation of the instance name.
{code}
Caused by: java.lang.IllegalArgumentException: Object 'j' doesn't match dns
naming constraints. Reason: Can't be null or empty. Length must be 3 to 63
symbols..
at
org.jclouds.predicates.validators.DnsNameValidator.exception(DnsNameValidator.java:74)
at
org.jclouds.predicates.validators.DnsNameValidator.validate(DnsNameValidator.java:51)
at
org.jclouds.predicates.validators.DnsNameValidator.validate(DnsNameValidator.java:36)
at
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.checkGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:124)
at
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.sharedNameForGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:120)
at
org.jclouds.googlecomputeengine.compute.functions.FirewallTagNamingConvention$Factory.get(FirewallTagNamingConvention.java:39)
at
org.jclouds.googlecomputeengine.compute.functions.InstanceInZoneToNodeMetadata.apply(InstanceInZoneToNodeMetadata.java:89)
at
org.jclouds.googlecomputeengine.compute.functions.InstanceInZoneToNodeMetadata.apply(InstanceInZoneToNodeMetadata.java:51)
at
shaded.com.google.common.base.Functions$FunctionComposition.apply(Functions.java:216)
at
shaded.com.google.common.collect.Iterators$8.transform(Iterators.java:799)
at
shaded.com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at
shaded.com.google.common.collect.Iterators$7.computeNext(Iterators.java:651)
at
shaded.com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at
shaded.com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at shaded.com.google.common.collect.Iterators.addAll(Iterators.java:361)
at shaded.com.google.common.collect.Iterables.addAll(Iterables.java:354)
at shaded.com.google.common.collect.Sets.newLinkedHashSet(Sets.java:328)
at
org.jclouds.compute.internal.BaseComputeService.listNodes(BaseComputeService.java:335)
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
com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:40)
at com.sun.proxy.$Proxy107.listNodes(Unknown Source)
at
jenkins.plugins.jclouds.compute.JCloudsCloud.getRunningNodesCount(JCloudsCloud.java:389)
at
jenkins.plugins.jclouds.compute.JCloudsCloud.doProvision(JCloudsCloud.java:372)
... 73 more
{code}
*Note*: I have only tested this with version 1.8.1 and I am calling jclouds
from inside a jenkins plugin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [jclouds-labs-google] WIP: JCLOUDS-908 fix to InstanceToNodeMetadata (#139)
If I understand this correctly that loss of functionality means that we would be returning the tags we create internally for the firewall when returning the NodeMetadata object, instead of hiding them? If this is the case I think that's perfectly fine and I'd go ahead with this approach. There's no hard need to hide this kind of info to users. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/139#issuecomment-104037284
Re: [jclouds-labs-google] WIP: JCLOUDS-908 fix to InstanceToNodeMetadata (#139)
You understand correctly. I think it was more important when we were adding more then one tag to instances. Ill go ahead and remove it. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/139#issuecomment-104038082
[jira] [Commented] (JCLOUDS-908) BaseComputeService#listNodes throwing an exception
[
https://issues.apache.org/jira/browse/JCLOUDS-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14553002#comment-14553002
]
Daniel Broudy commented on JCLOUDS-908:
---
Do we want to filter out instances that do not match the naming convention when
we do BaseComputeService#listNodes like we do with firewall tags or do we want
to display all instances?
BaseComputeService#listNodes throwing an exception
--
Key: JCLOUDS-908
URL: https://issues.apache.org/jira/browse/JCLOUDS-908
Project: jclouds
Issue Type: Sub-task
Components: jclouds-compute, jclouds-labs-google
Affects Versions: 1.8.1, 1.9.0
Reporter: Pedro Ribeiro
If I have an instance named j-t2, then when I call
BaseComputeService#listNodes, I get the following error. The 'j' in the
exception seems to result from some manipulation of the instance name.
{code}
Caused by: java.lang.IllegalArgumentException: Object 'j' doesn't match dns
naming constraints. Reason: Can't be null or empty. Length must be 3 to 63
symbols..
at
org.jclouds.predicates.validators.DnsNameValidator.exception(DnsNameValidator.java:74)
at
org.jclouds.predicates.validators.DnsNameValidator.validate(DnsNameValidator.java:51)
at
org.jclouds.predicates.validators.DnsNameValidator.validate(DnsNameValidator.java:36)
at
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.checkGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:124)
at
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.sharedNameForGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:120)
at
org.jclouds.googlecomputeengine.compute.functions.FirewallTagNamingConvention$Factory.get(FirewallTagNamingConvention.java:39)
at
org.jclouds.googlecomputeengine.compute.functions.InstanceInZoneToNodeMetadata.apply(InstanceInZoneToNodeMetadata.java:89)
at
org.jclouds.googlecomputeengine.compute.functions.InstanceInZoneToNodeMetadata.apply(InstanceInZoneToNodeMetadata.java:51)
at
shaded.com.google.common.base.Functions$FunctionComposition.apply(Functions.java:216)
at
shaded.com.google.common.collect.Iterators$8.transform(Iterators.java:799)
at
shaded.com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at
shaded.com.google.common.collect.Iterators$7.computeNext(Iterators.java:651)
at
shaded.com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at
shaded.com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at shaded.com.google.common.collect.Iterators.addAll(Iterators.java:361)
at shaded.com.google.common.collect.Iterables.addAll(Iterables.java:354)
at shaded.com.google.common.collect.Sets.newLinkedHashSet(Sets.java:328)
at
org.jclouds.compute.internal.BaseComputeService.listNodes(BaseComputeService.java:335)
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
com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:40)
at com.sun.proxy.$Proxy107.listNodes(Unknown Source)
at
jenkins.plugins.jclouds.compute.JCloudsCloud.getRunningNodesCount(JCloudsCloud.java:389)
at
jenkins.plugins.jclouds.compute.JCloudsCloud.doProvision(JCloudsCloud.java:372)
... 73 more
{code}
*Note*: I have only tested this with version 1.8.1 and I am calling jclouds
from inside a jenkins plugin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [jclouds] Adds autovalue/gson builders tests, for sanity. (#699)
@nacx @andrewgaul Good news, everybody! 1.1 is out. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/699#issuecomment-104045580
[jira] [Commented] (JCLOUDS-908) BaseComputeService#listNodes throwing an exception
[
https://issues.apache.org/jira/browse/JCLOUDS-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14553051#comment-14553051
]
Ignasi Barrera commented on JCLOUDS-908:
Agree, we should try to show them all.
BaseComputeService#listNodes throwing an exception
--
Key: JCLOUDS-908
URL: https://issues.apache.org/jira/browse/JCLOUDS-908
Project: jclouds
Issue Type: Sub-task
Components: jclouds-compute, jclouds-labs-google
Affects Versions: 1.8.1, 1.9.0
Reporter: Pedro Ribeiro
If I have an instance named j-t2, then when I call
BaseComputeService#listNodes, I get the following error. The 'j' in the
exception seems to result from some manipulation of the instance name.
{code}
Caused by: java.lang.IllegalArgumentException: Object 'j' doesn't match dns
naming constraints. Reason: Can't be null or empty. Length must be 3 to 63
symbols..
at
org.jclouds.predicates.validators.DnsNameValidator.exception(DnsNameValidator.java:74)
at
org.jclouds.predicates.validators.DnsNameValidator.validate(DnsNameValidator.java:51)
at
org.jclouds.predicates.validators.DnsNameValidator.validate(DnsNameValidator.java:36)
at
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.checkGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:124)
at
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.sharedNameForGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:120)
at
org.jclouds.googlecomputeengine.compute.functions.FirewallTagNamingConvention$Factory.get(FirewallTagNamingConvention.java:39)
at
org.jclouds.googlecomputeengine.compute.functions.InstanceInZoneToNodeMetadata.apply(InstanceInZoneToNodeMetadata.java:89)
at
org.jclouds.googlecomputeengine.compute.functions.InstanceInZoneToNodeMetadata.apply(InstanceInZoneToNodeMetadata.java:51)
at
shaded.com.google.common.base.Functions$FunctionComposition.apply(Functions.java:216)
at
shaded.com.google.common.collect.Iterators$8.transform(Iterators.java:799)
at
shaded.com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at
shaded.com.google.common.collect.Iterators$7.computeNext(Iterators.java:651)
at
shaded.com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at
shaded.com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at shaded.com.google.common.collect.Iterators.addAll(Iterators.java:361)
at shaded.com.google.common.collect.Iterables.addAll(Iterables.java:354)
at shaded.com.google.common.collect.Sets.newLinkedHashSet(Sets.java:328)
at
org.jclouds.compute.internal.BaseComputeService.listNodes(BaseComputeService.java:335)
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
com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:40)
at com.sun.proxy.$Proxy107.listNodes(Unknown Source)
at
jenkins.plugins.jclouds.compute.JCloudsCloud.getRunningNodesCount(JCloudsCloud.java:389)
at
jenkins.plugins.jclouds.compute.JCloudsCloud.doProvision(JCloudsCloud.java:372)
... 73 more
{code}
*Note*: I have only tested this with version 1.8.1 and I am calling jclouds
from inside a jenkins plugin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-908) BaseComputeService#listNodes throwing an exception
[
https://issues.apache.org/jira/browse/JCLOUDS-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14553070#comment-14553070
]
Daniel Broudy commented on JCLOUDS-908:
---
I created a WIP PR with two proposed options.
https://github.com/jclouds/jclouds-labs-google/pull/139
BaseComputeService#listNodes throwing an exception
--
Key: JCLOUDS-908
URL: https://issues.apache.org/jira/browse/JCLOUDS-908
Project: jclouds
Issue Type: Sub-task
Components: jclouds-compute, jclouds-labs-google
Affects Versions: 1.8.1, 1.9.0
Reporter: Pedro Ribeiro
If I have an instance named j-t2, then when I call
BaseComputeService#listNodes, I get the following error. The 'j' in the
exception seems to result from some manipulation of the instance name.
{code}
Caused by: java.lang.IllegalArgumentException: Object 'j' doesn't match dns
naming constraints. Reason: Can't be null or empty. Length must be 3 to 63
symbols..
at
org.jclouds.predicates.validators.DnsNameValidator.exception(DnsNameValidator.java:74)
at
org.jclouds.predicates.validators.DnsNameValidator.validate(DnsNameValidator.java:51)
at
org.jclouds.predicates.validators.DnsNameValidator.validate(DnsNameValidator.java:36)
at
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.checkGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:124)
at
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.sharedNameForGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:120)
at
org.jclouds.googlecomputeengine.compute.functions.FirewallTagNamingConvention$Factory.get(FirewallTagNamingConvention.java:39)
at
org.jclouds.googlecomputeengine.compute.functions.InstanceInZoneToNodeMetadata.apply(InstanceInZoneToNodeMetadata.java:89)
at
org.jclouds.googlecomputeengine.compute.functions.InstanceInZoneToNodeMetadata.apply(InstanceInZoneToNodeMetadata.java:51)
at
shaded.com.google.common.base.Functions$FunctionComposition.apply(Functions.java:216)
at
shaded.com.google.common.collect.Iterators$8.transform(Iterators.java:799)
at
shaded.com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at
shaded.com.google.common.collect.Iterators$7.computeNext(Iterators.java:651)
at
shaded.com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at
shaded.com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at shaded.com.google.common.collect.Iterators.addAll(Iterators.java:361)
at shaded.com.google.common.collect.Iterables.addAll(Iterables.java:354)
at shaded.com.google.common.collect.Sets.newLinkedHashSet(Sets.java:328)
at
org.jclouds.compute.internal.BaseComputeService.listNodes(BaseComputeService.java:335)
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
com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:40)
at com.sun.proxy.$Proxy107.listNodes(Unknown Source)
at
jenkins.plugins.jclouds.compute.JCloudsCloud.getRunningNodesCount(JCloudsCloud.java:389)
at
jenkins.plugins.jclouds.compute.JCloudsCloud.doProvision(JCloudsCloud.java:372)
... 73 more
{code}
*Note*: I have only tested this with version 1.8.1 and I am calling jclouds
from inside a jenkins plugin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-798) getting OutOfMemory while fetching images from aws
[
https://issues.apache.org/jira/browse/JCLOUDS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14552847#comment-14552847
]
Subhadip commented on JCLOUDS-798:
--
Hi,
Just to update. This was resolved.
getting OutOfMemory while fetching images from aws
--
Key: JCLOUDS-798
URL: https://issues.apache.org/jira/browse/JCLOUDS-798
Project: jclouds
Issue Type: Bug
Components: jclouds-compute, jclouds-core
Affects Versions: 1.7.3
Environment: jdk 1.7, windows 7
Reporter: Subhadip
Hi,
While fetching the selfImages from aws suddenly I'm started getting OOM
error. below is my code to fetch images. Please help to resolve the issue.
{code:language=java}
try {
ComputeServiceContext computeServiceContext =
getComputeContext(cloudType);
ComputeService computeService = computeServiceContext
.getComputeService();
if (null != computeService null !=
computeService.listImages()) {
for (Image image : computeService.listImages())
{
templateBean = new TemplateBean();
templateBean.setImageId(image.getId());
templateBean.setTemplateName(image.getName());
templateBean.setCloudType(cloudType);
if
(Constants.AWS_EC2.equalsIgnoreCase(cloudType)) {
templateBean.setZoneId(AP_SOUTHEAST_1);
}
list.add(templateBean);
}
imageList = new TemplatesBean();
imageList.setName(cloudType);
imageList.setImages(list);
templateStatusBean.setTemplatesBean(imageList);
} else {
errorBean
.setErrorCode(ErrorCode.COMPUTE_SERVICE.getErrorCode());
errorBean.setErrorMessage(ErrorCode.COMPUTE_SERVICE
.getMessage());
templateStatusBean.setErrorBean(errorBean);
}
} catch (Exception exception) {
LOG.warn(exception, exception);
errorBean.setErrorCode(ErrorCode.SELF_IMAGE_ISSUE.getErrorCode());
errorBean.setErrorMessage(ErrorCode.SELF_IMAGE_ISSUE.getMessage()
+ : + exception.getMessage());
templateStatusBean.setErrorBean(errorBean);
}
return templateStatusBean;
}
{code}
I'm getting the below exceptions in apache tomcat... saying the rest call for
http connection of jclouds is failing.
{noformat}
SEVERE: Servlet.service() for servlet [spring] in context with path
[/aricloud] threw exception [Handler processing failed; nested exception is
com.google.common.util.concurrent.ExecutionError:
com.google.common.util.concurrent.ExecutionError:
com.google.common.util.concurrent.ExecutionError: java.lang.OutOfMemoryError:
unable to create new native thread] with root cause
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:640)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1188)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1215)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1199)
at
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
at
sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1031)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:230)
at
org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.writePayloadToConnection(JavaUrlHttpCommandExecutorService.java:305)
at
org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.convert(JavaUrlHttpCommandExecutorService.java:192)
at
Re: [jclouds] Adds autovalue/gson builders tests, for sanity. (#699)
Closed #699. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/699#event-310103610
Re: [jclouds] Adds autovalue/gson builders tests, for sanity. (#699)
Reopened #699. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/699#event-310103618
Re: [jclouds] JCLOUDS-903 - Support nova compute api extension server groups (#748)
@@ -36,7 +35,7 @@ public NovaComputeServiceLiveTest() {
provider = openstack-nova;
}
- @Override
+@Override
?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/748/files#r30762757
Re: [jclouds] JCLOUDS-903 - Support nova compute api extension server groups (#748)
+
+ public T fromSecurityGroup(ServerGroup in) {
+ return this
+ .id(in.getId())
+ .policies(in.getPolicies());
+ }
+ }
+
+ private static class ConcreteBuilder extends BuilderConcreteBuilder {
+ @Override
+ protected ConcreteBuilder self() {
+ return this;
+ }
+ }
+
+private final String id;
Formatting looks strange
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/748/files#r30762560
Re: [jclouds] JCLOUDS-903 - Support nova compute api extension server groups (#748)
+ * Scheduler hints extension (alias OS-SCH-HNT): Hints passed directly to
the scheduler via /servers POST
+ *
+ * @see a
href=http://developer.openstack.org/api-ref-compute-v2-ext.html#createServer;
/
+ *
+ * Currently contains support for server group based filters only
+ * a
href=http://docs.openstack.org/havana/config-reference/content/scheduler-filters.html#groupaffinityfilterGroupAffinity/a
+ * and a
href=http://docs.openstack.org/havana/config-reference/content/scheduler-filters.html#groupantiaffinityfilterGroupAntiAffinity/a
+ * Can be easily augmented to add support for other filters that can be
configured via scheduler hints
+*/
+public class SchedulerHints {
+
+ public static Builder builder() {
+ return new ConcreteBuilder();
+ }
+
+ public Builder toBuilder() {
Do we want to move to the autovalue builders for this?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/748/files#r30762533
[jira] [Commented] (JCLOUDS-613) Implement the DigitalOcean v2 API
[ https://issues.apache.org/jira/browse/JCLOUDS-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14553228#comment-14553228 ] Ignasi Barrera commented on JCLOUDS-613: Just a heads up: pagination is implemented now in: https://github.com/nacx/jclouds-labs/tree/do-pagination, which is forked directly from your fork. There are several other changes in that branch too I found when reading the docs to implement the pagination: * I renamed some classes to DigitalOcean2 to keep consistency with the naming of the metadata and api classes. * I refactored the model so all classes use google auto (like the OperatingSystem and Snapshot), and fixed some fields: dates are now Date objects, etc. Also aligned all nullable annotations with what their docs say. * Fetched some unit tests from the v1 provider and adapted them to the new one. * Added a DigitalOcean specific base class for the mock tests. * Implemented the mock tests for the size, region and action APIs. I haven't run yet the live tests and it is possible that the changes in the model (specifically the nullable thing has broken something), because I want to implement all mock tests first. I plan to work on finishing all mock tests this week and also implement the remaining API specific live tests that could be missing. Implement the DigitalOcean v2 API - Key: JCLOUDS-613 URL: https://issues.apache.org/jira/browse/JCLOUDS-613 Project: jclouds Issue Type: New Feature Components: jclouds-compute Affects Versions: 1.7.3 Reporter: Ignasi Barrera Assignee: Ignasi Barrera Labels: digitalocean Fix For: 2.0.0 DigitalOcean has just released the version 2 of their API. It introduces some major changes as long as many improvements and features that make the API more easy to consume. Version 2 is now a more RESTful API, has a better error population (and hope this will help us get rid of the [custom HTTP response parsing code|https://github.com/jclouds/jclouds-labs/blob/master/digitalocean/src/main/java/org/jclouds/digitalocean/http/ResponseStatusFromPayloadHttpCommandExecutorService.java#L89-L128]), and and a more complete domain model. https://www.digitalocean.com/company/blog/api-v2-enters-public-beta/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jclouds-labs-google] WIP: JCLOUDS-908 fix to InstanceToNodeMetadata (#139)
When do you think we will do another release? If it is soon I would consider adding the try-catch block to catch the IllegalArgumentException as a temporary solution to deal with instance names triggering exceptions and then encourage people to upgrade to the new version when it is released. I am hesitant to backport everything because it is tough to reason about the effects of the change on users and unexpected change is bad. That being said, as long as you don't backport removing network from GoogleComputeEngineTemplate options, the main negative side effect I would foresee is resources not being deleted when users expected them to be. (ie. When users delete all nodes in a group the network will not be deleted.) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/139#issuecomment-104074798
Re: [jclouds] JCLOUDS-903 - Support nova compute api extension server groups (#748)
@@ -914,7 +912,7 @@ protected void tearDownContext() {
// Destroy all nodes in the group but also make sure to destroy
other created nodes that might not be in it.
// The testCreateTwoNodesWithOneSpecifiedName creates nodes
with an explicit name that puts them outside the group,
// so the list of nodes should also be taken into account when
destroying the nodes.
-client.destroyNodesMatching(Predicates.NodeMetadata
or(inGroup(group), in(nodes)));
+
computeService.destroyNodesMatching(Predicates.NodeMetadataor(inGroup(group),
in(nodes)));
}
} catch (Exception e) {
Thanks for the cleanup!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/748/files#r30763106
Re: [jclouds] JCLOUDS-903 - Support nova compute api extension server groups (#748)
+import org.testng.annotations.Test;
+
+import java.net.URI;
+import java.util.Set;
+
+import static org.testng.Assert.assertEquals;
+import static org.testng.Assert.assertFalse;
+import static org.testng.Assert.assertNull;
+import static org.testng.Assert.assertTrue;
+
+
+/**
+ * Tests ServerGroupApi guice wiring and parsing
+ */
+@Test(groups = unit, testName = ServerGroupApiExpectTest)
+public class ServerGroupApiExpectTest extends BaseNovaApiExpectTest {
Is it feasible to switch to mock tests here in line with how new code is being
implemented? Or do we want to keep expect tests for consistency.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/748/files#r30762831
Re: [jclouds-labs-google] WIP: JCLOUDS-908 fix to InstanceToNodeMetadata (#139)
Change lgtm. Thinking about the impact of this issue, we should backport it to 1.9.x. However, the firewall refactor was not backported there as changes the functionality internally (although it doesn't change the public interfaces). Do you think it is worth backporting the firewall changes there too? Could that break existing code that deals with previously creteated instances and firewalls? Or is it OK to just apply this fix there and return *all* the tags? I'm fine backporting everything, as it improves usability and removes the limitation of the number of firewalls created. Also, GCE is still in labs (^^), so it should be ok to backport such a change. WDYT? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/139#issuecomment-104061189
Re: [jclouds-labs-google] WIP: JCLOUDS-908 fix to InstanceToNodeMetadata (#139)
rebuild please --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/139#issuecomment-104072636
Re: [jclouds] JCLOUDS-903 - Support nova compute api extension server groups (#748)
+@Beta
+@Extension(of = ServiceType.COMPUTE, namespace =
ExtensionNamespaces.SERVER_GROUPS)
+@RequestFilters(AuthenticateRequest.class)
+@Consumes(MediaType.APPLICATION_JSON)
+public interface ServerGroupApi {
+ /**
+* List all Security Groups.
+*
+* @return all Security Groups
+*/
+ @Named(ServerGroup:list)
+ @GET
+ @Path(/os-server-groups)
+ @SelectJson(server_groups)
+ @Fallback(EmptyFluentIterableOnNotFoundOr404.class)
+ FluentIterableServerGroup list();
We should avoid using guava collections in user-facing interfaces. Also - does
this need paging support?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/748/files#r30762622
Re: [jclouds] JCLOUDS-903 - Support nova compute api extension server groups (#748)
@@ -132,7 +134,57 @@ public void testCreateWithNetworkOptions() {
}
}
- /**
+/**
+ * This test creates a server with a scheduler hint that sets the server
group
+ * used for a
href=http://docs.openstack.org/havana/config-reference/content/scheduler-filters.html#groupaffinityfilterGroupAffinity/a
I rather have the info directly in here in addition to the links
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/748/files#r30763006
Re: [jclouds] add aws s3 signature v4 (#678)
try Multipart Upload. initiate Multipart Upload..temporarily store specific length part, upload all stream part..complete multipart upload... part requires Content-Length. not all a file. but I have not tried :) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/678#issuecomment-104135788
