Re: [jclouds] Delete objects in a container efficiently. (#214)
[jclouds-java-7-pull-requests #1165](https://jclouds.ci.cloudbees.com/job/jclouds-java-7-pull-requests/1165/) SUCCESS This pull request looks good --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/214#issuecomment-38656006
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
I think the whole authentication login with these ssh connections needs a rethink at some point (hopefully not with this pull request though). The way I, as a user, would like it to work is that I just pile on authentication methods that have some hope of succeeding and then when connecting we run through those until one succeeds or we run out of candidates. As it currently is implemented, the connections will only try ssh-agent if there is no other method defined. Also the ```isAvailable()``` logic and how it is used inside the agent proxy librabry is very limited currently. For example on windows that will always return true and this will lead to ```createConnector()``` returning a ```PageantConnector``` regardless of whether one is actually running. Also there is no way of using the OpenSSH ssh-agent on windows currently. I imagine it would require some extra code since on unixes the communication goes over unix sockets with jna native integration. However these are limitations in jsch-agentproxy implementation. And IMO this pull request represents functionality that is significantly better than having no ssh-agent support. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38659488
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
@@ -152,7 +163,7 @@ public void clear() {
}
@Override
- public Session create() throws Exception {
+ public synchronized Session create() throws Exception {
Have you experienced concurrency issues? In theory, the ssh client factory will
create independent clients, and each one will have its own connection. Is there
any use case where the same client and connection is used simultaneously by
different users/clients/actors? (Such use case does not exist in
jclouds-compute).
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/312/files#r10967503
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
@@ -63,9 +77,14 @@ public Factory(ProxyConfig proxyConfig,
BackoffLimitedRetryHandler backoffLimite
@Override
public SshClient create(HostAndPort socket, LoginCredentials
credentials) {
- SshClient client = new JschSshClient(proxyConfig,
backoffLimitedRetryHandler, socket, credentials, timeout);
+ SshClient client = new JschSshClient(proxyConfig,
backoffLimitedRetryHandler, socket, credentials, timeout,
getAgentConnector());
Reuse the `agentConnector` variable, as it is already initialized?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/312/files#r10967539
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
@@ -63,9 +77,14 @@ public Factory(ProxyConfig proxyConfig,
BackoffLimitedRetryHandler backoffLimite
@Override
public SshClient create(HostAndPort socket, LoginCredentials
credentials) {
- SshClient client = new JschSshClient(proxyConfig,
backoffLimitedRetryHandler, socket, credentials, timeout);
+ SshClient client = new JschSshClient(proxyConfig,
backoffLimitedRetryHandler, socket, credentials, timeout,
getAgentConnector());
Since Factory is a singleton, then all connections would share the same
connector? Would you rather protect against potential concurrency problems only
when you run into them?
My use case only uses one ssh connection so right now this would not affect me
either way...
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/312/files#r10967937
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
@@ -156,6 +157,15 @@ public String getPrivateKey() {
}
/**
+* @return true if there is a private key attached that is not encrypted
+*/
+ public boolean hasUnencryptedPrivateKey() {
+ return getPrivateKey() != null
+ !getPrivateKey().isEmpty()
+ !getPrivateKey().contains(Pems.PROC_TYPE_ENCRYPTED);
OK, makes sense then. Do we need a case-insensitive comparison here, perhaps?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/312/files#r10974718
Re: [jclouds] Implement a poor-mans rollback if static nat creation fails (#184)
@demobox @nacx Been a while, but it works fine with current master. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/184#issuecomment-38692063
[jclouds] JCLOUDS-347 Implement a poor-mans rollback if static nat creation fails (#328)
As discussed in https://github.com/jclouds/jclouds/pull/184 here is a new patch for master. Cheers, Hugo You can merge this Pull Request by running: git pull https://github.com/spark404/jclouds JCLOUDS-347-1.8.x Or you can view, comment on it, or merge it online at: https://github.com/jclouds/jclouds/pull/328 -- Commit Summary -- * Implement a poor-mans rollback if static nat creation fails -- File Changes -- M apis/cloudstack/src/main/java/org/jclouds/cloudstack/compute/strategy/CloudStackComputeServiceAdapter.java (44) -- Patch Links -- https://github.com/jclouds/jclouds/pull/328.patch https://github.com/jclouds/jclouds/pull/328.diff --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/328
Re: [jclouds] JCLOUDS-347 Implement a poor-mans rollback if static nat creation fails (#328)
[jclouds » jclouds #953](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/953/) SUCCESS This pull request looks good [(what's this?)](https://www.cloudbees.com/what-is-buildhive) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/328#issuecomment-38699461
Re: [jclouds] JCLOUDS-347 Implement a poor-mans rollback if static nat creation fails (#328)
[jclouds-pull-requests #697](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/697/) UNSTABLE Looks like there's a problem with this pull request --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/328#issuecomment-38700999
Re: [jclouds] Refactor SoftLayer CCI support (#296)
[jclouds » jclouds #954](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/954/) UNSTABLE Looks like there's a problem with this pull request [(what's this?)](https://www.cloudbees.com/what-is-buildhive) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/296#issuecomment-38706561
Re: [jclouds] Refactor SoftLayer CCI support (#296)
[jclouds-pull-requests #699](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/699/) UNSTABLE Looks like there's a problem with this pull request --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/296#issuecomment-38707059
Re: [jclouds] Refactor SoftLayer CCI support (#296)
[jclouds-pull-requests #698](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/698/) SUCCESS This pull request looks good --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/296#issuecomment-38707154
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
@@ -152,7 +163,7 @@ public void clear() {
}
@Override
- public Session create() throws Exception {
+ public synchronized Session create() throws Exception {
I'd say yes. There is no direct use case in jclouds where a client is
shared between multiple actors, so I'd just remove it.
Thanks!
El 26/03/2014 18:19, psiniemi notificati...@github.com escribió:
In drivers/jsch/src/main/java/org/jclouds/ssh/jsch/SessionConnection.java:
@@ -152,7 +163,7 @@ public void clear() {
}
@Override
- public Session create() throws Exception {
+ public synchronized Session create() throws Exception {
So if one client is only ever used to create one session, there is no need
for synchronization here. Shall I just remove it?
--
Reply to this email directly or view it on
GitHubhttps://github.com/jclouds/jclouds/pull/312/files#r10987347
.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/312/files#r10988944
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
[jclouds-pull-requests #700](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/700/) SUCCESS This pull request looks good --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38724118
[jira] [Updated] (JCLOUDS-515) Cinder volume create does not require availability zone
[ https://issues.apache.org/jira/browse/JCLOUDS-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Everett Toews updated JCLOUDS-515: -- Assignee: Jasdeep Hundal Cinder volume create does not require availability zone --- Key: JCLOUDS-515 URL: https://issues.apache.org/jira/browse/JCLOUDS-515 Project: jclouds Issue Type: Bug Components: jclouds-core Affects Versions: 1.7.1 Reporter: Jasdeep Hundal Assignee: Jasdeep Hundal Fix For: 1.8.0 Openstack Cinder does not require specifying an availability zone for volume creation, but the Cinder API as implemented in JClouds does. We should change the check in the constructor of org.jclouds.openstack.cinder.v1.domain to allow a null value for availability zone. The docs on the v1 API are not readily available but tracing through the Cinder source code, we find this line that gets executed if we specify no availability zone in either the v1 or v2 block storage APIs: https://github.com/openstack/cinder/blob/master/cinder/volume/flows/api/create_volume.py#L247 It can also be noted the the Block Storage v2 request here does not require an availability zone: http://docs.openstack.org/api/openstack-block-storage/2.0/content/POST_createVolume_v2__tenant_id__volumes_Volumes.html -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [jclouds] JCLOUDS-515: Don't require availability zone when creating volumes in cinder (#327)
[jclouds » jclouds #956](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/956/) SUCCESS This pull request looks good [(what's this?)](https://www.cloudbees.com/what-is-buildhive) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/327#issuecomment-38728902
Re: [jclouds] Refactor SoftLayer CCI support (#296)
[jclouds-pull-requests #702](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/702/) UNSTABLE Looks like there's a problem with this pull request --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/296#issuecomment-38732537
Re: [jclouds] Refactor SoftLayer CCI support (#296)
[jclouds » jclouds #957](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/957/) UNSTABLE Looks like there's a problem with this pull request [(what's this?)](https://www.cloudbees.com/what-is-buildhive) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/296#issuecomment-38734577
Jenkins build became unstable: jclouds » jclouds #957
See https://buildhive.cloudbees.com/job/jclouds/job/jclouds/957/changes
Re: [jclouds] JCLOUDS-515: Don't require availability zone when creating volumes in cinder (#327)
@nacx : I removed the zone specification from the test and it passed, so I think this is good to go. Could add another test to use zone as well, but I'm not sure how valuable an additional test just for that will be. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/327#issuecomment-38735446
[jira] [Commented] (JCLOUDS-515) Cinder volume create does not require availability zone
[ https://issues.apache.org/jira/browse/JCLOUDS-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948419#comment-13948419 ] Everett Toews commented on JCLOUDS-515: --- The Volume domain object is not actually used to create volumes. Rather, it's the immutable object returned by Cinder when the create call is done. From create_volume.py we see that Cinder always sets the availability zone no matter what so this value should always be present when the create call is done. From VolumeApi.create(int , CreateVolumeOptions...) we can see that the CreateVolumeOptions object is responsible for supplying the options during the create call. It's here where you can optionally supply the availability zone with something like CreateVolumeOptions.Builder.availabilityZone(nova). AFAICT, this change isn't necessary unless I've mischaracterized the issue. Jasdeep, do you have a code snippet demonstrating the problem? Cinder volume create does not require availability zone --- Key: JCLOUDS-515 URL: https://issues.apache.org/jira/browse/JCLOUDS-515 Project: jclouds Issue Type: Bug Components: jclouds-core Affects Versions: 1.7.1 Reporter: Jasdeep Hundal Assignee: Jasdeep Hundal Fix For: 1.8.0 Openstack Cinder does not require specifying an availability zone for volume creation, but the Cinder API as implemented in JClouds does. We should change the check in the constructor of org.jclouds.openstack.cinder.v1.domain to allow a null value for availability zone. The docs on the v1 API are not readily available but tracing through the Cinder source code, we find this line that gets executed if we specify no availability zone in either the v1 or v2 block storage APIs: https://github.com/openstack/cinder/blob/master/cinder/volume/flows/api/create_volume.py#L247 It can also be noted the the Block Storage v2 request here does not require an availability zone: http://docs.openstack.org/api/openstack-block-storage/2.0/content/POST_createVolume_v2__tenant_id__volumes_Volumes.html -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [jclouds] JCLOUDS-515: Don't require availability zone when creating volumes in cinder (#327)
@jasdeep-hundal @nacx I made [a comment](https://issues.apache.org/jira/browse/JCLOUDS-515?focusedCommentId=13948419page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13948419) that was more appropriate to be made over in the issue. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/327#issuecomment-38736206
Re: [jclouds] Delete objects in a container efficiently. (#214)
}
- private boolean parentIsFolder(final ListContainerOptions options, final
StorageMetadata md) {
- return options.getDir() != null md.getName().indexOf('/') == -1;
+ private void waitForCompletion(final Semaphore semaphore,
+ final SetListenableFutureVoid outstandingFutures) {
+ // Wait for all futures to complete by waiting to acquire all
+ // semaphores.
+ try {
+ // TODO: Each individual blob delete operation itself has a time
+ // limit of 'maxTime'. Therefore having a time limit for this
+ // semaphore acquisition provides little value. This could be
+ // removed.
I removed the timeout as the comment suggests since we can easily encounter
this situation with large containers.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/214/files#r10997822
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
Only the minor question about a possible case-insensitive check for the encrypted header from me, otherwise +1 - looks good. @nacx: Any more questions from you? I guess we want want to backport this to 1.7.x? And we should probably create an issue for this, just for housekeeping... --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38737396
Re: [jclouds] Delete objects in a container efficiently. (#214)
I committed to master with some Checkstyle, Javadoc, and indentation fixes. Let's address some of the TODOs and test more before backporting to 1.7.x. Thank you for your contribution @shrinandj ! The previous implementation has troubled us for some years now. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/214#issuecomment-38737591
Re: [jclouds] Delete objects in a container efficiently. (#214)
Closed #214. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/214
[jira] [Commented] (JCLOUDS-510) Head-of-line blocking problem with DeleteAllKeysInList
[ https://issues.apache.org/jira/browse/JCLOUDS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948439#comment-13948439 ] ASF subversion and git services commented on JCLOUDS-510: - Commit 655aa444d71d8a24ac831fa4c3d365042c4a8ebb in jclouds's branch refs/heads/master from [~shrinand] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=655aa44 ] JCLOUDS-510 Delete objects in a container efficiently. The existing approach for deleting objects in a container suffers from a head-of-line blocking problem. This commit implements a better scheme which does not have that problem. This scheme uses a counting semaphore for making sure that a certain number of futures are issued in parallel. As each of these futures is completed, one permit of the semaphore is released. Added unit tests for testing this new scheme. Head-of-line blocking problem with DeleteAllKeysInList -- Key: JCLOUDS-510 URL: https://issues.apache.org/jira/browse/JCLOUDS-510 Project: jclouds Issue Type: Improvement Components: jclouds-blobstore Affects Versions: 1.8.0, 1.7.1 Reporter: Shri Javadekar Assignee: Shri Javadekar Fix For: 1.8.0, 1.7.2 The current implementation of DeleteAllKeysInList suffers from the head-of-line blocking problem. It gets a PageSet of blobs from the container, creates futures for deleting them and waits for the futures to complete before getting the next PageSet. This issue was originally reported by Andrew Gaul [~gaul] [1] -Shri [1] https://github.com/jclouds/legacy-jclouds/issues/1087 -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [jclouds] JCLOUDS-515: Don't require availability zone when creating volumes in cinder (#327)
I made a comment that was more appropriate to be made over in the issue. Good catch, @everett-toews. Thanks! --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/327#issuecomment-38738453
Re: [jclouds] WIP JCLOUDS-514: Add ability to attach block volumes at boot through the Nova ServerApi (#326)
@@ -102,6 +103,27 @@ public String toString() {
}
+ public static class BlockDevice{
Are you confident that BlockDevice will only ever be used within the context of
CreateServerOptions?
Also there should be a space before the {
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/326/files#r10998875
Re: [jclouds] WIP JCLOUDS-514: Add ability to attach block volumes at boot through the Nova ServerApi (#326)
@@ -102,6 +103,27 @@ public String toString() {
}
+ public static class BlockDevice{
Going to work through getting this running through the ComputeServiceApi this
week, should have a good answer for you then. Right now, I'm not sure.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/326/files#r10999079
Re: [jclouds] WIP JCLOUDS-514: Add ability to attach block volumes at boot through the Nova ServerApi (#326)
@@ -102,6 +103,27 @@ public String toString() {
}
+ public static class BlockDevice{
+ @Named(volume_size)
+ String volumeSize = ;
+ @Named(volume_id)
+ String volumeId;
+ @Named(delete_on_termination)
+ int deleteOnTermination = 0;
+ @Named(device_name)
+ String deviceName;
+
+ public BlockDevice(String volumeId, String deviceName){
+ this(volumeId, deviceName, true);
+ }
+
+ public BlockDevice(String volumeId, String deviceName, boolean
deleteWhenInstanceTerminated){
We don't typically expose ctors like here and above directly. These should be
factory methods.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/326/files#r10999095
Re: [jclouds] WIP JCLOUDS-514: Add ability to attach block volumes at boot through the Nova ServerApi (#326)
@@ -102,6 +103,27 @@ public String toString() {
}
+ public static class BlockDevice{
+ @Named(volume_size)
+ String volumeSize = ;
+ @Named(volume_id)
+ String volumeId;
+ @Named(delete_on_termination)
+ int deleteOnTermination = 0;
+ @Named(device_name)
+ String deviceName;
+
+ public BlockDevice(String volumeId, String deviceName){
[minor] Space before `{`
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/326/files#r10999123
Re: [jclouds] WIP JCLOUDS-514: Add ability to attach block volumes at boot through the Nova ServerApi (#326)
+ String volumeSize = ;
+ @Named(volume_id)
+ String volumeId;
+ @Named(delete_on_termination)
+ int deleteOnTermination = 0;
+ @Named(device_name)
+ String deviceName;
+
+ public BlockDevice(String volumeId, String deviceName){
+ this(volumeId, deviceName, true);
+ }
+
+ public BlockDevice(String volumeId, String deviceName, boolean
deleteWhenInstanceTerminated){
+ this.volumeId = volumeId;
+ this.deviceName = deviceName;
+ this.deleteOnTermination = deleteWhenInstanceTerminated ? 1 : 0;
No need to use a different parameter name here. @everett-toews: would you
normally do something like creating constants for 0 and 1 here? Or is there
some kind of boolean to string JSON mapper we could use?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/326/files#r10999246
Re: [jclouds] WIP JCLOUDS-514: Add ability to attach block volumes at boot through the Nova ServerApi (#326)
@@ -113,6 +135,7 @@ public String toString() {
private SetNetwork novaNetworks = ImmutableSet.of();
private String availabilityZone;
private boolean configDrive;
+ private ListBlockDevice blockDeviceMapping = Lists.newArrayList();
`ImmutableList.of()`?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/326/files#r10999274
Re: [jclouds] WIP JCLOUDS-514: Add ability to attach block volumes at boot through the Nova ServerApi (#326)
@@ -463,6 +494,21 @@ public CreateServerOptions networks(String... networks) {
return networks(ImmutableSet.copyOf(networks));
}
+ /**
+* Block volumes that should be attached to the instance at boot time
+*/
+ public ListBlockDevice getBlockDeviceMapping() {
+ return blockDeviceMapping;
+ }
Can you move this method to after `blockDeviceMapping`? A cleanup of this class
that untangled the current mix of getters and builder option methods would be
nice, but that's not really part of this PR, I guess.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/326/files#r10999601
Re: [jclouds] WIP JCLOUDS-514: Add ability to attach block volumes at boot through the Nova ServerApi (#326)
@@ -463,6 +494,21 @@ public CreateServerOptions networks(String... networks) {
return networks(ImmutableSet.copyOf(networks));
}
+ /**
+* Block volumes that should be attached to the instance at boot time
+*/
+ public ListBlockDevice getBlockDeviceMapping() {
+ return blockDeviceMapping;
+ }
+
+ /**
+* @see #getBlockDeviceMapping
+*/
+ public CreateServerOptions blockDeviceMapping(ListBlockDevice
blockDeviceMapping) {
+ this.blockDeviceMapping = blockDeviceMapping;
`ImmutableList.copyOf(blockDeviceMapping)`
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/326/files#r10999736
[jira] [Commented] (JCLOUDS-514) Need to be able to attach block volumes at instance creation in Nova
[ https://issues.apache.org/jira/browse/JCLOUDS-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948481#comment-13948481 ] Everett Toews commented on JCLOUDS-514: --- The two CLI docs linked to here seem to be for two different things. The (Grizzly and older) link is for attaching a volume on boot, whereas the (Icehouse) link is for booting from a volume, snapshot, or image. What's the intent of this change? If it's just attaching on boot then please remove the (Icehouse) link. Need to be able to attach block volumes at instance creation in Nova Key: JCLOUDS-514 URL: https://issues.apache.org/jira/browse/JCLOUDS-514 Project: jclouds Issue Type: New Feature Components: jclouds-compute, jclouds-core Reporter: Jasdeep Hundal Labels: features Fix For: 1.8.0 The Nova API allows for attaching block volumes to an instance at creation time, it would be nice to access this feature through JClouds. See: - (Grizzly and older): http://docs.openstack.org/grizzly/openstack-compute/admin/content/instance-creation.html - (Icehouse): http://docs.openstack.org/user-guide/content/create_volume_from_image_and_boot.html -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [jclouds] WIP JCLOUDS-514: Add ability to attach block volumes at boot through the Nova ServerApi (#326)
@@ -102,6 +103,27 @@ public String toString() {
}
+ public static class BlockDevice{
My suggestion would be to get it running properly in the NovaApi with expect
tests and live tests first. That stuff really needs to be done before you can
add proper support in the ComputeService anyway. We'll wind up with a better
feature this way.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/326/files#r11000148
Re: [jclouds] WIP JCLOUDS-514: Add ability to attach block volumes at boot through the Nova ServerApi (#326)
We'll also need more Javadoc for all of the parameters that can be used to create a BlockDevice. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/326#issuecomment-38742092
[jira] [Commented] (JCLOUDS-514) Need to be able to attach block volumes at instance creation in Nova
[ https://issues.apache.org/jira/browse/JCLOUDS-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948499#comment-13948499 ] Jasdeep Hundal commented on JCLOUDS-514: That was a bit for a derp on a blind copy for other things I was doing, just pasted the Nova request json now. Need to be able to attach block volumes at instance creation in Nova Key: JCLOUDS-514 URL: https://issues.apache.org/jira/browse/JCLOUDS-514 Project: jclouds Issue Type: New Feature Components: jclouds-compute, jclouds-core Reporter: Jasdeep Hundal Labels: features Fix For: 1.8.0 The Nova API allows for attaching block volumes to an instance at creation time, it would be nice to access this feature through JClouds. See: - (Grizzly and older): http://docs.openstack.org/grizzly/openstack-compute/admin/content/instance-creation.html - (Icehouse): http://docs.openstack.org/user-guide/content/create_volume_from_image_and_boot.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (JCLOUDS-514) Need to be able to attach block volumes at instance creation in Nova
[
https://issues.apache.org/jira/browse/JCLOUDS-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948511#comment-13948511
]
Everett Toews commented on JCLOUDS-514:
---
I think the (Icehouse) link you really want is
http://docs.openstack.org/user-guide/content/create_new_volume_before_instance.html
That's to Attach non-bootable volume to an instance. The URL is horribly
misleading.
What do you think?
Need to be able to attach block volumes at instance creation in Nova
Key: JCLOUDS-514
URL: https://issues.apache.org/jira/browse/JCLOUDS-514
Project: jclouds
Issue Type: New Feature
Components: jclouds-compute, jclouds-core
Reporter: Jasdeep Hundal
Labels: features
Fix For: 1.8.0
The Nova API allows for attaching block volumes to an instance at creation
time, it would be nice to access this feature through JClouds.
Example Nova JSON:
{server: {name: jasdeep-test, imageRef:
ed5912af-ff25-4ff3-bbec-6c00898c14b8, block_device_mapping:
[{volume_size: , volume_id: f696b2aa-4c83-40ad-ab25-984b59dd2e3c,
delete_on_termination: 1, device_name: vda}], flavorRef: small,
max_count: 1, min_count: 1}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JCLOUDS-514) Need to be able to attach block volumes at instance creation in Nova
[
https://issues.apache.org/jira/browse/JCLOUDS-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948520#comment-13948520
]
Everett Toews commented on JCLOUDS-514:
---
For the record, there are two similarly named things that were causing me a bit
of confusion.
AFAICT, when booting a Nova server you can attach block devices or boot from
block devices. The flags in the Nova are similar:
block-device-mapping == attach block devices
block-device == boot from block device
Need to be able to attach block volumes at instance creation in Nova
Key: JCLOUDS-514
URL: https://issues.apache.org/jira/browse/JCLOUDS-514
Project: jclouds
Issue Type: New Feature
Components: jclouds-compute, jclouds-core
Reporter: Jasdeep Hundal
Labels: features
Fix For: 1.8.0
The Nova API allows for attaching block volumes to an instance at creation
time, it would be nice to access this feature through JClouds.
Example Nova JSON:
{server: {name: jasdeep-test, imageRef:
ed5912af-ff25-4ff3-bbec-6c00898c14b8, block_device_mapping:
[{volume_size: , volume_id: f696b2aa-4c83-40ad-ab25-984b59dd2e3c,
delete_on_termination: 1, device_name: vda}], flavorRef: small,
max_count: 1, min_count: 1}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: [jclouds] WIP JCLOUDS-514: Add ability to attach block volumes at boot through the Nova ServerApi (#326)
@@ -102,6 +103,27 @@ public String toString() {
}
+ public static class BlockDevice{
Considering there's already a feature in Nova that boots from block devices
using the term block-device, I think it's more appropriate to call this object
BlockDeviceMapping.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/326/files#r11001032
Re: [jclouds-labs-openstack] OS Neutron Extension Router (#83)
jclouds-labs-openstack-pull-requests #185 UNSTABLE Glance tests [are failing](https://jclouds.ci.cloudbees.com/job/jclouds-labs-openstack-pull-requests/org.apache.jclouds.labs$openstack-glance/185/testReport/) - I guess you are expecting that, @zack-shoylev? If I recall, we had a follow-up PR to this planned soon. Could we address the following [Checkstyle violations](https://jclouds.ci.cloudbees.com/job/jclouds-labs-openstack-pull-requests/185/org.apache.jclouds.labs$openstack-neutron/violations/) that we have introduced with this PR? Thanks! --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-openstack/pull/83#issuecomment-38744058
[jira] [Commented] (JCLOUDS-514) Need to be able to attach block volumes at instance creation in Nova
[
https://issues.apache.org/jira/browse/JCLOUDS-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948524#comment-13948524
]
Jasdeep Hundal commented on JCLOUDS-514:
This ticket is specifically for attaching, though I think the mechanism may be
the same, just that we don't specify an image when we intend to boot from
volume.
Need to be able to attach block volumes at instance creation in Nova
Key: JCLOUDS-514
URL: https://issues.apache.org/jira/browse/JCLOUDS-514
Project: jclouds
Issue Type: New Feature
Components: jclouds-compute, jclouds-core
Reporter: Jasdeep Hundal
Labels: features
Fix For: 1.8.0
The Nova API allows for attaching block volumes to an instance at creation
time, it would be nice to access this feature through JClouds.
Example Nova JSON:
{server: {name: jasdeep-test, imageRef:
ed5912af-ff25-4ff3-bbec-6c00898c14b8, block_device_mapping:
[{volume_size: , volume_id: f696b2aa-4c83-40ad-ab25-984b59dd2e3c,
delete_on_termination: 1, device_name: vda}], flavorRef: small,
max_count: 1, min_count: 1}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Jenkins build is back to stable : jclouds » jclouds #958
See https://buildhive.cloudbees.com/job/jclouds/job/jclouds/958/changes
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
[jclouds » jclouds #958](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/958/) SUCCESS This pull request looks good [(what's this?)](https://www.cloudbees.com/what-is-buildhive) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38744806
Re: [jclouds] JCLOUDS-515: Don't require availability zone when creating volumes in cinder (#327)
Yep, I see now (and agree). Thx @everett-toews ! --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/327#issuecomment-38744957
[jira] [Comment Edited] (JCLOUDS-515) Cinder volume create does not require availability zone
[
https://issues.apache.org/jira/browse/JCLOUDS-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948531#comment-13948531
]
Jasdeep Hundal edited comment on JCLOUDS-515 at 3/26/14 9:57 PM:
-
This was a fix because I did run into this, and probably should have pasted
that in the ticket... :P
Code:
{code:title=CinderVolumeCreate.java|borderStyle=solid}
Properties properties = new Properties();
// Assume properties set properly
CinderApi cinderApi = builder.overrides(properties).buildApi(CinderApi.class);
VolumeApi cinderVolumeApi = cinderApi.getVolumeApiForZone(RegionOne);
CreateVolumeOptions volumeOptions = new CreateVolumeOptions();
volumeOptions.name(test);
volumeOptions.volumeType(type);
cinderVolumeApi.create(size, volumeOptions);
{code}
Traceback:
{code}
java.lang.NullPointerException: zone
at
com.google.common.base.Preconditions.checkNotNull(Preconditions.java:229)
at org.jclouds.openstack.cinder.v1.domain.Volume.init(Volume.java:244)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at
com.google.common.reflect.Invokable$ConstructorInvokable.invokeInternal(Invokable.java:242)
at com.google.common.reflect.Invokable.invoke(Invokable.java:102)
at
org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.newInstance(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:215)
at
org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.read(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:195)
at com.google.gson.Gson.fromJson(Gson.java:803)
at
org.jclouds.http.functions.ParseFirstJsonValueNamed.apply(ParseFirstJsonValueNamed.java:83)
at
org.jclouds.http.functions.ParseFirstJsonValueNamed.apply(ParseFirstJsonValueNamed.java:47)
at
org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:93)
at
org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:76)
at
org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:47)
at
org.jclouds.reflect.FunctionalReflection$FunctionalInvocationHandler.handleInvocation(FunctionalReflection.java:117)
at
com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:87)
at com.sun.proxy.$Proxy89.create(Unknown Source)
...
{code}
was (Author: jasdeep):
This was a fix because I did run into this, and probably should have pasted
that in the ticket... :P
Code:
{code:title=CinderVolumeCreate.java|borderStyle=solid}
Properties properties = new Properties();
// Assume properties set properly
CinderApi cinderApi = builder.overrides(properties).buildApi(CinderApi.class);
VolumeApi cinderVolumeApi = cinderApi.getVolumeApiForZone(RegionOne);
CreateVolumeOptions volumeOptions = new CreateVolumeOptions();
volumeOptions.name(name);
volumeOptions.volumeType(nebula);
cinderVolumeApi.create(size, volumeOptions);
{code}
Traceback:
{code}
java.lang.NullPointerException: zone
at
com.google.common.base.Preconditions.checkNotNull(Preconditions.java:229)
at org.jclouds.openstack.cinder.v1.domain.Volume.init(Volume.java:244)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at
com.google.common.reflect.Invokable$ConstructorInvokable.invokeInternal(Invokable.java:242)
at com.google.common.reflect.Invokable.invoke(Invokable.java:102)
at
org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.newInstance(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:215)
at
org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.read(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:195)
at com.google.gson.Gson.fromJson(Gson.java:803)
at
org.jclouds.http.functions.ParseFirstJsonValueNamed.apply(ParseFirstJsonValueNamed.java:83)
at
org.jclouds.http.functions.ParseFirstJsonValueNamed.apply(ParseFirstJsonValueNamed.java:47)
at
[jira] [Commented] (JCLOUDS-515) Cinder volume create does not require availability zone
[
https://issues.apache.org/jira/browse/JCLOUDS-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948531#comment-13948531
]
Jasdeep Hundal commented on JCLOUDS-515:
This was a fix because I did run into this, and probably should have pasted
that in the ticket... :P
Code:
{code:title=CinderVolumeCreate.java|borderStyle=solid}
Properties properties = new Properties();
// Assume properties set properly
CinderApi cinderApi = builder.overrides(properties).buildApi(CinderApi.class);
VolumeApi cinderVolumeApi = cinderApi.getVolumeApiForZone(RegionOne);
CreateVolumeOptions volumeOptions = new CreateVolumeOptions();
volumeOptions.name(name);
volumeOptions.volumeType(nebula);
cinderVolumeApi.create(size, volumeOptions);
{code}
Traceback:
{code}
java.lang.NullPointerException: zone
at
com.google.common.base.Preconditions.checkNotNull(Preconditions.java:229)
at org.jclouds.openstack.cinder.v1.domain.Volume.init(Volume.java:244)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at
com.google.common.reflect.Invokable$ConstructorInvokable.invokeInternal(Invokable.java:242)
at com.google.common.reflect.Invokable.invoke(Invokable.java:102)
at
org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.newInstance(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:215)
at
org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.read(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:195)
at com.google.gson.Gson.fromJson(Gson.java:803)
at
org.jclouds.http.functions.ParseFirstJsonValueNamed.apply(ParseFirstJsonValueNamed.java:83)
at
org.jclouds.http.functions.ParseFirstJsonValueNamed.apply(ParseFirstJsonValueNamed.java:47)
at
org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:93)
at
org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:76)
at
org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:47)
at
org.jclouds.reflect.FunctionalReflection$FunctionalInvocationHandler.handleInvocation(FunctionalReflection.java:117)
at
com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:87)
at com.sun.proxy.$Proxy89.create(Unknown Source)
...
{code}
Cinder volume create does not require availability zone
---
Key: JCLOUDS-515
URL: https://issues.apache.org/jira/browse/JCLOUDS-515
Project: jclouds
Issue Type: Bug
Components: jclouds-core
Affects Versions: 1.7.1
Reporter: Jasdeep Hundal
Assignee: Jasdeep Hundal
Fix For: 1.8.0
Openstack Cinder does not require specifying an availability zone for volume
creation, but the Cinder API as implemented in JClouds does. We should change
the check in the constructor of org.jclouds.openstack.cinder.v1.domain to
allow a null value for availability zone.
The docs on the v1 API are not readily available but tracing through the
Cinder source code, we find this line that gets executed if we specify no
availability zone in either the v1 or v2 block storage APIs:
https://github.com/openstack/cinder/blob/master/cinder/volume/flows/api/create_volume.py#L247
It can also be noted the the Block Storage v2 request here does not require
an availability zone:
http://docs.openstack.org/api/openstack-block-storage/2.0/content/POST_createVolume_v2__tenant_id__volumes_Volumes.html
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JCLOUDS-515) Cinder volume create does not require availability zone
[ https://issues.apache.org/jira/browse/JCLOUDS-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948532#comment-13948532 ] Jasdeep Hundal commented on JCLOUDS-515: Ah, I realize after looking at this end result of this, the volume was created, but constructing the Volume object as the return value is what failed. Cinder volume create does not require availability zone --- Key: JCLOUDS-515 URL: https://issues.apache.org/jira/browse/JCLOUDS-515 Project: jclouds Issue Type: Bug Components: jclouds-core Affects Versions: 1.7.1 Reporter: Jasdeep Hundal Assignee: Jasdeep Hundal Fix For: 1.8.0 Openstack Cinder does not require specifying an availability zone for volume creation, but the Cinder API as implemented in JClouds does. We should change the check in the constructor of org.jclouds.openstack.cinder.v1.domain to allow a null value for availability zone. The docs on the v1 API are not readily available but tracing through the Cinder source code, we find this line that gets executed if we specify no availability zone in either the v1 or v2 block storage APIs: https://github.com/openstack/cinder/blob/master/cinder/volume/flows/api/create_volume.py#L247 It can also be noted the the Block Storage v2 request here does not require an availability zone: http://docs.openstack.org/api/openstack-block-storage/2.0/content/POST_createVolume_v2__tenant_id__volumes_Volumes.html -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [jclouds] JCLOUDS-515: Don't require availability zone when creating volumes in cinder (#327)
Thanks @everett-toews , I was a little quick to jump the gun there. Left a comment in the ticket, but there is a fix that needs to be made, not sure if it is this one though. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/327#issuecomment-38746123
Re: [jclouds] WIP JCLOUDS-514: Add ability to attach block volumes at boot through the Nova ServerApi (#326)
@@ -102,6 +103,27 @@ public String toString() {
}
+ public static class BlockDevice{
Will go that route, and I'm fine with that name change (I actually started out
with that and then noticed that Nova called the entire list of block device
mappings a block device mapping itself.)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/326/files#r11002003
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
[jclouds-pull-requests #703](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/703/) SUCCESS This pull request looks good --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38746443
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
Only the minor question about a possible case-insensitive check for the encrypted header from me @demobox Reading [the spec of the Proc-Type header](http://tools.ietf.org/html/rfc1421#section-4.6.1.1) it seems that the possible values are fixed and uppercase, so I'm ok with the current check being case sensitive. If you're ok too I'll merge it in a while. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38746959
[jira] [Commented] (JCLOUDS-515) Cinder volume create does not require availability zone
[ https://issues.apache.org/jira/browse/JCLOUDS-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948551#comment-13948551 ] Jasdeep Hundal commented on JCLOUDS-515: ^ Investigating that now. Cinder volume create does not require availability zone --- Key: JCLOUDS-515 URL: https://issues.apache.org/jira/browse/JCLOUDS-515 Project: jclouds Issue Type: Bug Components: jclouds-core Affects Versions: 1.7.1 Reporter: Jasdeep Hundal Assignee: Jasdeep Hundal Fix For: 1.8.0 Openstack Cinder does not require specifying an availability zone for volume creation, but the Cinder API as implemented in JClouds does. We should change the check in the constructor of org.jclouds.openstack.cinder.v1.domain to allow a null value for availability zone. The docs on the v1 API are not readily available but tracing through the Cinder source code, we find this line that gets executed if we specify no availability zone in either the v1 or v2 block storage APIs: https://github.com/openstack/cinder/blob/master/cinder/volume/flows/api/create_volume.py#L247 It can also be noted the the Block Storage v2 request here does not require an availability zone: http://docs.openstack.org/api/openstack-block-storage/2.0/content/POST_createVolume_v2__tenant_id__volumes_Volumes.html -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
Just seen that the comparison is now case-insensitive. A case-sensitive check, as it was done before, seems more correct. Mind changing this last small bit? I'll merge it afterwards. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38747495
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
[jclouds-java-7-pull-requests #1173](https://jclouds.ci.cloudbees.com/job/jclouds-java-7-pull-requests/1173/) SUCCESS This pull request looks good --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38747539
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
so I'm ok with the current check being case sensitive Thanks for checking the spec, @nacx. Lazy me :-( Good to go on this one - just the usual squash'n'rebase, and an issue number! --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38748053
[jira] [Commented] (JCLOUDS-515) Cinder volume create does not require availability zone
[ https://issues.apache.org/jira/browse/JCLOUDS-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948585#comment-13948585 ] Andrew Phillips commented on JCLOUDS-515: - Yes, this looks like it's happening when deserializing the return value. But if that's true, then it would seem to be at odds with [~everett-toews]'s comment that From create_volume.py we see that Cinder always sets the availability zone no matter what so this value should always be present when the create call is done. Curious to see where the bug chips will fall! Cinder volume create does not require availability zone --- Key: JCLOUDS-515 URL: https://issues.apache.org/jira/browse/JCLOUDS-515 Project: jclouds Issue Type: Bug Components: jclouds-core Affects Versions: 1.7.1 Reporter: Jasdeep Hundal Assignee: Jasdeep Hundal Fix For: 1.8.0 Openstack Cinder does not require specifying an availability zone for volume creation, but the Cinder API as implemented in JClouds does. We should change the check in the constructor of org.jclouds.openstack.cinder.v1.domain to allow a null value for availability zone. The docs on the v1 API are not readily available but tracing through the Cinder source code, we find this line that gets executed if we specify no availability zone in either the v1 or v2 block storage APIs: https://github.com/openstack/cinder/blob/master/cinder/volume/flows/api/create_volume.py#L247 It can also be noted the the Block Storage v2 request here does not require an availability zone: http://docs.openstack.org/api/openstack-block-storage/2.0/content/POST_createVolume_v2__tenant_id__volumes_Volumes.html -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [jclouds-labs-openstack] OS Neutron Extension Router (#83)
@demobox : Glance tests were fixed in another PR. I am working on follow up PRs and trying to determine scope. Thanks for reminding me about the needed checkstyle fixes. I will try to keep it in mind! :) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-openstack/pull/83#issuecomment-38750900
Re: [jclouds-labs-openstack] Updates to Rackspace Cloud Files CDN (#85)
return this;
}
public static class Builder {
- /** @see UpdateCDNContainerOptions#ttl */
+ /**
+ * @see UpdateCDNContainerOptions#ttl
There was a discussion regarding @see vs text in another PR recently. What is
the right approach?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/85/files#r11004177
[jira] [Commented] (JCLOUDS-508) Add length argument to SshClient.put() method
[ https://issues.apache.org/jira/browse/JCLOUDS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948618#comment-13948618 ] Andrew Gaul commented on JCLOUDS-508: - [~nwilton] ByteSource provides a size() method which you can populate ContentMetadata with. We have debated whether to implicitly populate this for ByteSourcePayload, similar to how ByteArrayPayload worked. It does seem like using an InputStreamPayload is dangerous here and we should provide a more eager error message in PutConnection. Add length argument to SshClient.put() method - Key: JCLOUDS-508 URL: https://issues.apache.org/jira/browse/JCLOUDS-508 Project: jclouds Issue Type: Improvement Components: jclouds-core Affects Versions: 1.7.1 Reporter: Nick Wilton Original Estimate: 1h Remaining Estimate: 1h Due to JCLOUDS-410 the only remaining Payload types are stream based. However, unfortunately the SshClient.put will not work unless a length is explicitly set using Payload.getContentMetadata().setContentLength(...), as the stream based payloads do not set this attribute (as there is no way of knowing how long a stream will be). Failure to set the content length, will cause a NullPointerException to occur in the net.schmizz.sshj library. I recommend that a length argument is added to the SshClient.put() argument, so that the user must specify the length when using this method. This is a much more friendly solution to modifying the payload meta data. Cheers. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [jclouds] JCLOUDS-347 Implement a poor-mans rollback if static nat creation fails (#328)
+vm =
client.getVirtualMachineApi().getVirtualMachine(vm.getId());
+ListInteger ports =
Ints.asList(templateOptions.getInboundPorts());
+if (capabilities.getCloudStackVersion().startsWith(2)) {
+ logger.debug( setting up IP forwarding for
IPAddress(%s) rules(%s), ip.getId(), ports);
+ SetIPForwardingRule rules =
setupPortForwardingRulesForIP.apply(ip, ports);
+ logger.trace( setup %d IP forwarding rules on
IPAddress(%s), rules.size(), ip.getId());
+} else {
+ logger.debug( setting up firewall rules for
IPAddress(%s) rules(%s), ip.getId(), ports);
+ SetFirewallRule rules =
setupFirewallRulesForIP.apply(ip, ports);
+ logger.trace( setup %d firewall rules on
IPAddress(%s), rules.size(), ip.getId());
+}
+ }
+ }
+ } catch (RuntimeException re) {
+ logger.error(-- exception after node has been created, trying to
destroy the created virtualMachine(%s), vm.getId());
+ destroyNode(vm.getId());
Do we need a `try...catch` around here, or can this not throw an exception?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/328/files#r11004547
Re: [jclouds] JCLOUDS-347 Implement a poor-mans rollback if static nat creation fails (#328)
+1 - seems saner to me. =) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/328#issuecomment-38753246
Re: [jclouds] JCLOUDS-515: Don't require availability zone when creating volumes in cinder (#327)
[jclouds » jclouds #960](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/960/) SUCCESS This pull request looks good [(what's this?)](https://www.cloudbees.com/what-is-buildhive) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/327#issuecomment-38763497
Re: [jclouds] JCLOUDS-515: Don't require availability zone when creating volumes in cinder (#327)
[jclouds-pull-requests #704](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/704/) SUCCESS This pull request looks good --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/327#issuecomment-38764216
[jira] [Updated] (JCLOUDS-509) Jclouds does not support AssociatePublicIpAddress attribute of EC2 RunInstances API
[ https://issues.apache.org/jira/browse/JCLOUDS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lahiru Sandaruwan updated JCLOUDS-509: -- Attachment: jclouds_patch.diff Attaching the patch. This includes update of AWS API to 2014-02-01. Please review. Jclouds does not support AssociatePublicIpAddress attribute of EC2 RunInstances API --- Key: JCLOUDS-509 URL: https://issues.apache.org/jira/browse/JCLOUDS-509 Project: jclouds Issue Type: Bug Reporter: Lahiru Sandaruwan Attachments: jclouds_patch.diff This is required if the instances that are created inside a VPC needs internet, and the VPC is not configured with a NAT network. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
Case insensitive now. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38771519
