@@ -90,7 +94,7 @@ private String parseMessage(HttpResponse response) {
try {
return
Strings2.toStringAndClose(response.getPayload().openStream());
} catch (IOException e) {
- throw Throwables.propagate(e);
+ return
Christopher Dancy created JCLOUDS-833:
-
Summary: Implement Service Key API in jclouds-labs-shipyard
provider
Key: JCLOUDS-833
URL: https://issues.apache.org/jira/browse/JCLOUDS-833
Project
[
https://issues.apache.org/jira/browse/JCLOUDS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14340153#comment-14340153
]
Christopher Dancy commented on JCLOUDS-833:
---
I (a.k.a. cdancy or dancc on IRC
+import javax.ws.rs.GET;
+import javax.ws.rs.Path;
+import javax.ws.rs.core.MediaType;
+
+import org.jclouds.Fallbacks.EmptyListOnNotFoundOr404;
+import org.jclouds.rest.annotations.EndpointParam;
+import org.jclouds.rest.annotations.Fallback;
+import
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License
@nacx rebased against master. All is working well now ;)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/116#issuecomment-75597979
@nacx thoughts on latest commit? Want to get the Ok with this latest round so
that I can then push live tests so we can close this PR and work on the next
set of commits for fleshing out Shipyard API (in a subsequent PR of course).
---
Reply to this email directly or view it on GitHub:
Very good. Been on vacation, not to mention a new baby, and just getting back
into the swing of things. I'll look into getting those tests submitted now that
this initial set of files is in good shape.
---
Reply to this email directly or view it on GitHub:
+ @Override
+ public Builder toBuilder() {
+ return new Builder().fromApiMetadata(this);
+ }
+
+ public ShipyardApiMetadata() {
+ this(new Builder());
+ }
+
+ protected ShipyardApiMetadata(Builder builder) {
+ super(builder);
+ }
+
+ public static
+case 402:
+ exception = new IllegalStateException(message, exception);
+ break;
+case 404:
+ if
(!command.getCurrentRequest().getMethod().equals(DELETE)) {
+ exception = new
+ *
+ * @see a href= http://en.wikipedia.org/wiki/Basic_access_authentication;
/
+ */
+@Singleton
+public class ServiceKeyAuthentication implements HttpRequestFilter {
+ private final SupplierCredentials creds;
+
+ @Inject
+ public ServiceKeyAuthentication(@Provider
+case 402:
+ exception = new IllegalStateException(message, exception);
+ break;
+case 404:
+ if
(!command.getCurrentRequest().getMethod().equals(DELETE)) {
+ exception = new
+/dependency
+dependency
+ groupIdcom.google.auto.value/groupId
+ artifactIdauto-value/artifactId
+ scopeprovided/scope
+/dependency
+dependency
+ groupIdorg.apache.jclouds.driver/groupId
+ artifactIdjclouds-slf4j/artifactId
+
+ @GET
+ @Path(/api/containers)
+ @Fallback(EmptyListOnNotFoundOr404.class)
+ ListContainerInfo listContainers();
+
+ @Named(containers:info)
+ @GET
+ @Path(/api/containers/{id})
+ @Fallback(NullOn500.class)
+ ContainerInfo getContainer(@PathParam(id) String id);
+
+ void deleteContainer(@PathParam(id) String id);
+
+ @Named(containers:stop)
+ @GET
+ @Path(/api/containers/{id}/stop)
+ void stopContainer(@PathParam(id) String id);
+
+ @Named(containers:restart)
+ @GET
+ @Path(/api/containers/{id}/restart)
+ void
+ exception = new AuthorizationException(message, exception);
+ break;
+case 402:
+ exception = new IllegalStateException(message, exception);
+ break;
+case 404:
+ if
+package org.jclouds.shipyard;
+
+import static org.testng.Assert.assertEquals;
+import static org.testng.Assert.assertNotNull;
+import static org.testng.Assert.assertTrue;
+
+import org.jclouds.apis.ApiMetadata;
+import org.jclouds.apis.Apis;
+import
+case 402:
+ exception = new IllegalStateException(message, exception);
+ break;
+case 404:
+ if
(!command.getCurrentRequest().getMethod().equals(DELETE)) {
+ exception = new
Thanks @nacx and yes it does. I've trimmed the file count down from 60 to 24.
Entire compute package has been removed. All features (minus ContainersApi,
ImagesApi, and EnginesApi) have been removed. You noted to keep only a single
feature, which I chose to be ContainersApi as that is the real
Initial commit for shipyard provider. My intent was to have the entire provider
coded and in something like good working shape before I submitted a PR but
@nacx strongly suggested I not do this.
This code base is a fork of the work @andreaturli is doing with docker so there
may be more than a
Anyway, I reverted to the previous impl with System.property but I really hope
we can find a final approach soon so that docker can go out of labs in the next
release
+1 (I'm following this PR. Any help you guys need, whether testing or something
else, feel free to reach out)
---
Reply to
Christopher Dancy created JCLOUDS-784:
-
Summary: jclouds-docker throws ISE when getting list of containers
Key: JCLOUDS-784
URL: https://issues.apache.org/jira/browse/JCLOUDS-784
Project: jclouds
Christopher Dancy created JCLOUDS-782:
-
Summary: Add Shipyard provider
Key: JCLOUDS-782
URL: https://issues.apache.org/jira/browse/JCLOUDS-782
Project: jclouds
Issue Type: New Feature
[
https://issues.apache.org/jira/browse/JCLOUDS-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Dancy updated JCLOUDS-782:
--
Description:
Add a provider for Shipyard to jclouds:
http://shipyard-project.com
Did this PR get merged? I ask only because the last github message here is
noting there are unmerged commits.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/419#issuecomment-48326473
It does and thank you ;)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/419#issuecomment-48329444
Good catch on the if statements.
As far as the Functions.compose is concerned: seems like we would lose the
ListenableFuture, that method createNodeInGroupWithNameAndTemplate returns, if
we go the Functions.compose route instead of Futures.transfrom?
---
Reply to this email directly or view it
Aaahhh how I forgot those 2, considering I was just in there poking around for
this very issue, I've no idea. Should be good now
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/425#issuecomment-48248928
Have not done a squash and rebase on my end yet. Just let me know when things
look good enough to do so.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/425#issuecomment-48254007
i know @nacx is in the same boat and while I think in theory the design is not
bad practice, and has its use-cases, I'm willing to concede that in this
context it may not be the best fit. I'll revert now and lets see where that
gets us.
---
Reply to this email directly or view it on GitHub:
I'd love some feedback on latest commit. Instead of pushing off the second PR
noted above I've included those proposed changed here as it's the proper way to
solve the problem instead of pushing it off to some later date. This will allow
us to do the following:
@@ -184,13 +207,25 @@ public boolean shouldAutoAssignFloatingIp() {
}
/**
+* The floating IP pool name(s) to use when allocating a FloatingIP.
Applicable
+* only if If #shouldGenerateKeyPair() returns true. If not set will
attempt to
Yes and yes. Fixing now ;)
---
}
-
+
on it
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/425/files#r14537102
+ floatingIpApi.addToServer(ip.get().getIp(), node.getProviderId());
+
input.get().getNodeMetadata().set(NodeMetadataBuilder.fromNodeMetadata(node).publicAddresses(ImmutableSet.of(ip.get().getIp())).build());
+
It was easier to keep the wrapped version inside
ApplyNovaTemplateOptionsCreateNodesWithGroupEncodedIntoNameThenAddToSet which
is why I did so. Let me see if I can clean things up a bit
---
Reply to this email directly or view it on GitHub:
@demobox looking over things I'm actually going to argue FOR keeping the
AtomicReferences inside NodeAndNovaTemplateOptions. The reason being is that we
are constantly passing around AtomicReferenceNodeMetadata and so it makes
things immensely easier to retrieve it rather than constantly
Also I see jenkins/cloudbees failing due to checkstyle issues. I'm using the
below checkstyle command on my code base and it's running fine.
mvn checkstyle:checkstyle --quiet -Dcheckstyle.output.file=/dev/stdout
-Dcheckstyle.output.format=plain
---
Reply to this email directly or view it on
@demobox clicking that link above gives this exception:
[ERROR]
/scratch/jenkins/workspace/jclouds-java-7-pull-requests/apis/openstack-nova/src/main/java/org/jclouds/openstack/nova/v2_0/compute/strategy/ApplyNovaTemplateOptionsCreateNodesWithGroupEncodedIntoNameThenAddToSet.java:[157,118]
Upon further thought I wonder if we should remove/deprecate the call to
create() altogether? Searching the internets I'm not the first to come across
this issue openstack. The create() call fails because it's not passing a
pool-name which I assume is why the allocate(String poolName) call was
Let's leave it open a while longer to see what others have to say. In testing
the 'create()' method is just making unnecessary http calls and filling up the
logs with the above. If we can agree on the above, meaning to deprecate, or at
the least don't use it at all, then I'll create a second PR
ip = floatingIpApi.create();
+ if(ip == null){
+ throw new InsufficientResourcesException();
+ }
You’ve got it right on controlling execution flow with exceptions but I opted
to go this route to keep as much existing code in place (whether for good or
@nacx not sure what unit tests I could write that's not already covered. I've
not actually written any new functionality just checked for a possible NPE.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/425#issuecomment-47665259
@demobox we can sneak that in
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/425#issuecomment-47667676
@@ -94,6 +97,12 @@ public boolean apply(FloatingIP arg0) {
// try to prevent multiple parallel launches from choosing the same
ip.
Collections.shuffle(unassignedIps);
ip = Iterables.getLast(unassignedIps);
+
+ //if we are still unable to
@@ -77,8 +77,11 @@ public
AllocateAndAddFloatingIpToNode(@Named(TIMEOUT_NODE_RUNNING) PredicateAto
FloatingIP ip = null;
try {
- logger.debug( allocating or reassigning floating ip for
node(%s), node.getId());
+ logger.debug( allocating or reassigning
@@ -94,6 +97,12 @@ public boolean apply(FloatingIP arg0) {
// try to prevent multiple parallel launches from choosing the same
ip.
Collections.shuffle(unassignedIps);
ip = Iterables.getLast(unassignedIps);
+
+ //if we are still unable to
@@ -94,6 +97,12 @@ public boolean apply(FloatingIP arg0) {
// try to prevent multiple parallel launches from choosing the same
ip.
Collections.shuffle(unassignedIps);
ip = Iterables.getLast(unassignedIps);
+
+ //if we are still unable to
@@ -94,6 +97,12 @@ public boolean apply(FloatingIP arg0) {
// try to prevent multiple parallel launches from choosing the same
ip.
Collections.shuffle(unassignedIps);
ip = Iterables.getLast(unassignedIps);
+
+ //if we are still unable to
Made minor commit to address formatting issues. I promise now that @nacx has
pointed me to the link below I will be less likely to submit spaghetti code ;)
https://wiki.apache.org/jclouds/Coding%20Standards
---
Reply to this email directly or view it on GitHub:
Addresses possible returned null value from #39;FloatingIPApi.create()#39;.
If upon check we find null then throw InsufficientResourcesException. This in
turn will make a second check at IP allocation by iterating through
#39;FloatingIPApi.list()#39; and grabbing an available IP. If this
@@ -94,6 +99,12 @@ public boolean apply(FloatingIP arg0) {
// try to prevent multiple parallel launches from choosing the same
ip.
Collections.shuffle(unassignedIps);
ip = Iterables.getLast(unassignedIps);
+
+ //if we are still unable to
ip = floatingIpApi.create();
+ if(ip == null){
+ throw new InsufficientResourcesException();
+ }
And therein lies the million dollar question! Because most of the code to
allocate, based on listed IP's, is inside the catch I left it there and I
think
Looks like there is an issue in trying to post to the dev mailing list
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/419#issuecomment-47385124
@ccustine is noting he tried and they are being returned ...
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/419#issuecomment-47406944
Yea that's true. I'd be interested to hear what others have to say.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/419#issuecomment-47247892
Just to close the loop on porting back ... change is backwards compatible in
that it does not break/change existing API's only what they return. Since
previous users expected nothing to come back they can happily go along thinking
so ;)
---
Reply to this email directly or view it on GitHub:
[
https://issues.apache.org/jira/browse/JCLOUDS-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Dancy closed JCLOUDS-581.
-
Resolution: Invalid
Upon further discussion this seems unnecessary.
Method calls
Yea I see your point. However I don't actually think anyone has been using
these methods anyway due to a bug I found here:
https://issues.apache.org/jira/browse/JCLOUDS-594
which @ccustine has fixed here:
https://github.com/jclouds/jclouds/pull/403
so with that in mind I wonder if it Ok to
@@ -423,24 +422,35 @@ public void rebootNode(String id) {
boolean successful = nodeRunning.apply(node);
logger.debug( rebooted node(%s) success(%s), id, successful);
}
-
+
I removed this package import as it was no longer being used. Should I add it
back?
---
Reply to
logger.debug( rebooting nodes matching(%s), filter);
-
transformParallel(nodesMatchingFilterAndNotTerminatedExceptionIfNotFound(filter),
-new FunctionNodeMetadata, ListenableFuture? extends Void() {
- // TODO use native async
- @Override
1.) Let me see what I can put together for better testing.
2.) I actually don't think that call is necessary and will remove. The
implementation was copied over from method destroyNodesMatching.
3.) Are you still against explicitly declaring we throw
TransformParallelException in
+new FunctionNodeMetadata, ListenableFuture? extends
NodeMetadata() {
+
+ // TODO make an async interface instead of re-wrapping
+ @Override
+ public ListenableFutureNodeMetadata apply(final
NodeMetadata from)
No I think in the end you're right. I guess from my POV I was expecting to see
it being declared as being thrown from somewhere. Digging through I see it
being thrown from inside FutureIterables.transformParallel, and I do understand
it's a RuntimeException, but some documentation as to say
squash/rebase done
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/419#issuecomment-47021203
@demobox to your last point: yea something like that would be perfect. I'll
make a mental note to go back at some point and make note of such things inside
code in a separate PR.
---
Reply to this email directly or view it on GitHub:
Christopher Dancy created JCLOUDS-610:
-
Summary: reboot, suspend, and resumeNodesMatching methods gain
functionality similar to that of destroyNodesMatching
Key: JCLOUDS-610
URL: https://issues.apache.org
This is the PR for this JIRA issue:
https://issues.apache.org/jira/browse/JCLOUDS-610
New tests have not been written as there are already the tests
quot;testRebootquot; and quot;testSuspendResumequot; of class
quot;BaseComputeServiceLiveTestquot; which already cover these calls. I have
Any idea when this is getting pulled? I've got a PR I'd like to send in that's
dependent on this working ;)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/403#issuecomment-46718075
Sorry to bother you on vacation! Hope it's a good one! I'll be patient a while
longer. It just appeared that this was lost in the mix of things and I wanted
to send another PR.
---
Reply to this email directly or view it on GitHub:
[
https://issues.apache.org/jira/browse/JCLOUDS-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037472#comment-14037472
]
Christopher Dancy commented on JCLOUDS-471:
---
Found a possible corner case. When
[
https://issues.apache.org/jira/browse/JCLOUDS-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Dancy reopened JCLOUDS-471:
---
Calling 'ComputeService.createNodesInGroup' whilst passing in a Template with
attached
Christopher Dancy created JCLOUDS-607:
-
Summary: ComputeService.createNodesInGroup throws NPE on
FloatingAPI.create()
Key: JCLOUDS-607
URL: https://issues.apache.org/jira/browse/JCLOUDS-607
[
https://issues.apache.org/jira/browse/JCLOUDS-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Dancy updated JCLOUDS-607:
--
Description:
When calling 'ComputeService.createNodesInGroup' an NPE is thrown
[
https://issues.apache.org/jira/browse/JCLOUDS-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Dancy updated JCLOUDS-607:
--
Description:
When calling 'ComputeService.createNodesInGroup' an NPE is thrown
This is my first commit but not on twitter. I am however on Facebook here:
https://www.facebook.com/christoforever
and googaplus here:
https://plus.google.com/+ChristopherDancy/posts
Looking forward to contributing more code and thanks for the help.
---
Reply to this email directly or view
@@ -267,7 +267,22 @@ public boolean apply(NodeMetadata nodeMetadata) {
@Override
public String toString() {
- return TERMINATED;
+ return Status.TERMINATED.toString();
+ }
+ };
+
+ /**
+* Match nodes with State == SUSPENDED
+*/
+
@@ -141,6 +141,19 @@ public void testNodeRunningReturnsTrueWhenRunning() {
Assert.assertTrue(nodeRunning.apply(reference));
Assert.assertEquals(reference.get(), node);
}
+
+ @Test
+ public void testNodeSuspendedReturnsTrueWhenSuspended() {
+
@@ -141,6 +141,19 @@ public void testNodeRunningReturnsTrueWhenRunning() {
Assert.assertTrue(nodeRunning.apply(reference));
Assert.assertEquals(reference.get(), node);
}
+
+ @Test
+ public void testNodeSuspendedReturnsTrueWhenSuspended() {
+
@@ -141,6 +141,19 @@ public void testNodeRunningReturnsTrueWhenRunning() {
Assert.assertTrue(nodeRunning.apply(reference));
Assert.assertEquals(reference.get(), node);
}
+
+ @Test
+ public void testNodeSuspendedReturnsTrueWhenSuspended() {
+
Rebase/squash is done. Should be good to go. Let me know if there is anything
you guys need and/or how it looks. As I mentioned elsewhere: this is my first
time working with git so I may have fudged something up.
---
Reply to this email directly or view it on GitHub:
[
https://issues.apache.org/jira/browse/JCLOUDS-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14029134#comment-14029134
]
Christopher Dancy commented on JCLOUDS-594:
---
Yea I saw the exception being
Just chiming in as I made the initial bug. If this could be back ported to at
least 1.7.3 that would be great.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/403#issuecomment-45899226
Christopher Dancy created JCLOUDS-596:
-
Summary: Add 'SUSPENDED' predicate to
org.jclouds.compute.predicates.NodePredicates
Key: JCLOUDS-596
URL: https://issues.apache.org/jira/browse/JCLOUDS-596
Added second commit to remove hard-coded strings inside
NodePredicates.name.toString methods which is just asking for a typo to pop.
Replaced hard-coded strings by calling their respective enum.toString() methods.
---
Reply to this email directly or view it on GitHub:
Just to clarify: the call DOES execute, and succeeds, but immediately throws an
exception afterward. When working with more than 1 vm/id the first of the set
succeeds but again immediately throws exception. All other vm/id's in set are
then ignored and/or not executed.
---
Reply to this email
Should be good to go. Nothing special just copied one of the previous testers
that fails when node is not running.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/405#issuecomment-45936032
Fix looks good to me
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/403#issuecomment-45942629
This was due to a misunderstanding, and lack of testing locally, for a code
block I assumed was fairly straight forward. Test passes locally and NOW should
be good to go ;)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/405#issuecomment-45944766
Christopher Dancy created JCLOUDS-594:
-
Summary: ComputeService.suspendNodesMatching throwing
UnsupportedOperationException but call still succeeds
Key: JCLOUDS-594
URL: https://issues.apache.org/jira/browse
[
https://issues.apache.org/jira/browse/JCLOUDS-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14019205#comment-14019205
]
Christopher Dancy commented on JCLOUDS-581:
---
Gotcha. It seems that if we were
Christopher Dancy created JCLOUDS-581:
-
Summary: Method calls startNodesMatching and stopNodesMatching
added to Base
Key: JCLOUDS-581
URL: https://issues.apache.org/jira/browse/JCLOUDS-581
[
https://issues.apache.org/jira/browse/JCLOUDS-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Dancy updated JCLOUDS-581:
--
Component/s: jclouds-compute
Description: Addition of methods
[
https://issues.apache.org/jira/browse/JCLOUDS-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017146#comment-14017146
]
Christopher Dancy commented on JCLOUDS-581:
---
They may very well be enough (I'm
101 - 193 of 193 matches
Mail list logo
