[jira] [Updated] (JCLOUDS-511) Incorrect feature definition: jclouds-rackspace-cloudblockstorage-uk/us
[
https://issues.apache.org/jira/browse/JCLOUDS-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated JCLOUDS-511:
-
Attachment: JCLOUDS-511.patch
Patch included with correct definition of
{{jclouds-api-rackspace-cloudidentity}} Karaf feature.
Incorrect feature definition: jclouds-rackspace-cloudblockstorage-uk/us
---
Key: JCLOUDS-511
URL: https://issues.apache.org/jira/browse/JCLOUDS-511
Project: jclouds
Issue Type: Bug
Components: jclouds-karaf
Affects Versions: 1.7.1
Reporter: Grzegorz Grzybek
Attachments: JCLOUDS-511.patch
For example, uk feature has the following definition:
{code:xml}
feature name='jclouds-rackspace-cloudblockstorage-uk' description='Racksapce
Cloud Block Storage UK' version='${project.version}' resolver='(obr)'
feature version='${project.version}'jclouds-api-openstack-cinder/feature
feature
version='${project.version}'jclouds-api-rackspace-cloudidentity/feature
bundlemvn:org.apache.jclouds.provider/rackspace-cloudblockstorage-uk/${jclouds.version}/bundle
/feature
{code}
and {{jclouds-api-rackspace-cloudidentity}}:
{code:xml}
feature name=jclouds-api-rackspace-cloudidentity description=Rackspace
Cloud Identity API version=${project.version} resolver=(obr)
feature version='${project.version}'jclouds-compute/feature
feature
version='${project.version}'jclouds-api-openstack-keystone/feature
bundle
dependency='true'mvn:org.apache.jclouds.api/rackspace-cloudidentity/${jclouds.version}/bundle
/feature
{code}
However, with current Karaf there's no way the bundle
mvn:org.apache.jclouds.api/rackspace-cloudidentity/${jclouds.version} will
get installed. Bundles with {dependency=true} are taken into account only
during resolution of other bundles from the same feature - not of the _upper_
feature which uses other features. In other words - {{bundle
dependency=true /}} doesn't _bubble up_.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
[jclouds » jclouds #941](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/941/) FAILURE 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/312#issuecomment-38432822
Re: [jclouds] 1.7.x Backport: Remove Nova instance metadata limit (#325)
+1 Thanks! About to merge. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/325#issuecomment-38456821
Re: [jclouds] 1.7.x Backport: Remove Nova instance metadata limit (#325)
merged, good to close. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/325#issuecomment-38460235
[jira] [Commented] (JCLOUDS-507) Nova instance metadata is not limited to 5 pairs
[ https://issues.apache.org/jira/browse/JCLOUDS-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945236#comment-13945236 ] ASF subversion and git services commented on JCLOUDS-507: - Commit 59c10e18e810a950fe24791fdb877860ac1ed120 in jclouds's branch refs/heads/1.7.x from [~jfriedly] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=59c10e1 ] Remove Nova instance metadata limit Rackspace cloud limits instance metadata to 5 key-value pairs, but upstream Nova only sets the limit at 128 by default. This patch removes the limit entirely; the official python clients don't check it and the server is responsible for enforcing it anyway. Fixes: https://issues.apache.org/jira/browse/JCLOUDS-507 Nova instance metadata is not limited to 5 pairs Key: JCLOUDS-507 URL: https://issues.apache.org/jira/browse/JCLOUDS-507 Project: jclouds Issue Type: Bug Components: jclouds-compute Affects Versions: 1.8.0 Reporter: Joel Friedly Priority: Minor Fix For: 1.8.0 The ``CreateServerOptions.metadata`` docs and method both say that only up to 5 key-value metadata pairs are allowed. This is a requirement of Rackspace cloud, but not of upstream OpenStack. There is a configurable metadata limit, the ``maxServerMeta`` nova absolute limit, but the default value is 128. The python nova client just sends requests up to nova though and the server enforces the limit. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [jclouds] Fixes potentially deleting a null server id. (#323)
I think we should be good just having this change on master..? Agreed. Thanks! --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/323#issuecomment-38460370
[jclouds-karaf] [JCLOUDS-511] Correcting features with dependency-only bundles (#40)
Features which had only bundles with `dependency=#39;true#39;` (they wouldn#39;t install in Karaf): * jclouds-api-rackspace-cloudidentity * jclouds-api-rackspace-clouddns You can merge this Pull Request by running: git pull https://github.com/grgrzybek/jclouds-karaf JCLOUDS-511 Or you can view, comment on it, or merge it online at: https://github.com/jclouds/jclouds-karaf/pull/40 -- Commit Summary -- * [JCLOUDS-511] Correcting features with dependency-only bundles -- File Changes -- M feature/src/main/resources/feature.xml (5) -- Patch Links -- https://github.com/jclouds/jclouds-karaf/pull/40.patch https://github.com/jclouds/jclouds-karaf/pull/40.diff --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-karaf/pull/40
[jira] [Commented] (JCLOUDS-511) Incorrect feature definition: jclouds-rackspace-cloudblockstorage-uk/us
[
https://issues.apache.org/jira/browse/JCLOUDS-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945278#comment-13945278
]
Grzegorz Grzybek commented on JCLOUDS-511:
--
Sorry. that's what I usually do ;)
Here it is: https://github.com/jclouds/jclouds-karaf/pull/40
Incorrect feature definition: jclouds-rackspace-cloudblockstorage-uk/us
---
Key: JCLOUDS-511
URL: https://issues.apache.org/jira/browse/JCLOUDS-511
Project: jclouds
Issue Type: Bug
Components: jclouds-karaf
Affects Versions: 1.7.1
Reporter: Grzegorz Grzybek
Attachments: JCLOUDS-511.patch
For example, uk feature has the following definition:
{code:xml}
feature name='jclouds-rackspace-cloudblockstorage-uk' description='Racksapce
Cloud Block Storage UK' version='${project.version}' resolver='(obr)'
feature version='${project.version}'jclouds-api-openstack-cinder/feature
feature
version='${project.version}'jclouds-api-rackspace-cloudidentity/feature
bundlemvn:org.apache.jclouds.provider/rackspace-cloudblockstorage-uk/${jclouds.version}/bundle
/feature
{code}
and {{jclouds-api-rackspace-cloudidentity}}:
{code:xml}
feature name=jclouds-api-rackspace-cloudidentity description=Rackspace
Cloud Identity API version=${project.version} resolver=(obr)
feature version='${project.version}'jclouds-compute/feature
feature
version='${project.version}'jclouds-api-openstack-keystone/feature
bundle
dependency='true'mvn:org.apache.jclouds.api/rackspace-cloudidentity/${jclouds.version}/bundle
/feature
{code}
However, with current Karaf there's no way the bundle
mvn:org.apache.jclouds.api/rackspace-cloudidentity/${jclouds.version} will
get installed. Bundles with {dependency=true} are taken into account only
during resolution of other bundles from the same feature - not of the _upper_
feature which uses other features. In other words - {{bundle
dependency=true /}} doesn't _bubble up_.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Jenkins build is back to normal : jclouds » jclouds #942
See https://buildhive.cloudbees.com/job/jclouds/job/jclouds/942/changes
Re: [jclouds-karaf] [JCLOUDS-511] Correcting features with dependency-only bundles (#40)
[jclouds » jclouds-karaf #822](https://buildhive.cloudbees.com/job/jclouds/job/jclouds-karaf/822/) 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-karaf/pull/40#issuecomment-38469757
Jenkins build is back to normal : jclouds » jclouds-chef #851
See https://buildhive.cloudbees.com/job/jclouds/job/jclouds-chef/851/
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
[jclouds-java-7-pull-requests #1156](https://jclouds.ci.cloudbees.com/job/jclouds-java-7-pull-requests/1156/) SUCCESS This pull request looks good --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38470229
Re: [jclouds-karaf] [JCLOUDS-511] Correcting features with dependency-only bundles (#40)
[jclouds-karaf-pull-requests #52](https://jclouds.ci.cloudbees.com/job/jclouds-karaf-pull-requests/52/) 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-karaf/pull/40#issuecomment-38470276
Jenkins build is back to normal : jclouds » jclouds-labs #891
See https://buildhive.cloudbees.com/job/jclouds/job/jclouds-labs/891/
Re: [jclouds] Remove Nova instance metadata limit (#324)
Closed #324. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/324
Re: [jclouds] 1.7.x Backport: Remove Nova instance metadata limit (#325)
Closed #325. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/325
Jenkins build became unstable: jclouds » jclouds-labs-openstack #943
See https://buildhive.cloudbees.com/job/jclouds/job/jclouds-labs-openstack/943/
[jira] [Updated] (JCLOUDS-507) Nova instance metadata is not limited to 5 pairs
[ https://issues.apache.org/jira/browse/JCLOUDS-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Friedly updated JCLOUDS-507: - Affects Version/s: 1.7.2 1.7.0 1.7.1 Fix Version/s: 1.7.2 Nova instance metadata is not limited to 5 pairs Key: JCLOUDS-507 URL: https://issues.apache.org/jira/browse/JCLOUDS-507 Project: jclouds Issue Type: Bug Components: jclouds-compute Affects Versions: 1.7.0, 1.8.0, 1.7.1, 1.7.2 Reporter: Joel Friedly Priority: Minor Fix For: 1.8.0, 1.7.2 The ``CreateServerOptions.metadata`` docs and method both say that only up to 5 key-value metadata pairs are allowed. This is a requirement of Rackspace cloud, but not of upstream OpenStack. There is a configurable metadata limit, the ``maxServerMeta`` nova absolute limit, but the default value is 128. The python nova client just sends requests up to nova though and the server enforces the limit. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (JCLOUDS-507) Nova instance metadata is not limited to 5 pairs
[ https://issues.apache.org/jira/browse/JCLOUDS-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Friedly resolved JCLOUDS-507. -- Resolution: Fixed Nova instance metadata is not limited to 5 pairs Key: JCLOUDS-507 URL: https://issues.apache.org/jira/browse/JCLOUDS-507 Project: jclouds Issue Type: Bug Components: jclouds-compute Affects Versions: 1.7.0, 1.8.0, 1.7.1, 1.7.2 Reporter: Joel Friedly Priority: Minor Fix For: 1.8.0, 1.7.2 The ``CreateServerOptions.metadata`` docs and method both say that only up to 5 key-value metadata pairs are allowed. This is a requirement of Rackspace cloud, but not of upstream OpenStack. There is a configurable metadata limit, the ``maxServerMeta`` nova absolute limit, but the default value is 128. The python nova client just sends requests up to nova though and the server enforces the limit. -- This message was sent by Atlassian JIRA (v6.2#6252)
Build failed in Jenkins: jclouds-labs-google-1.7.x-branch #75
See https://jclouds.ci.cloudbees.com/job/jclouds-labs-google-1.7.x-branch/75/ -- Started by upstream project jclouds-1.7.x-branch build number 55 originally caused by: Started by an SCM change Building remotely on 1f178878 in workspace https://jclouds.ci.cloudbees.com/job/jclouds-labs-google-1.7.x-branch/ws/ $ sudo /opt/jenkins/sbin/mount-webdav https://repository-jclouds.forge.cloudbees.com/private jclouds alert webdav mount try 1 p11-kit: couldn't read config file: /etc/pkcs11/modules/. Private webdav filestore is mounted Cloning the remote Git repository Cloning repository https://git-wip-us.apache.org/repos/asf/jclouds-labs-google.git FATAL: java.util.concurrent.ExecutionException: java.lang.NullPointerException hudson.remoting.RemotingSystemException: java.util.concurrent.ExecutionException: java.lang.NullPointerException at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:183) at com.sun.proxy.$Proxy6.fetch3(Unknown Source) at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:156) at java.lang.ClassLoader.loadClass(ClassLoader.java:425) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkCredentials(CliGitAPIImpl.java:1553) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:957) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$200(CliGitAPIImpl.java:71) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:197) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:329) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) 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:744) Caused by: java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask$Sync.innerGet(Unknown Source) at java.util.concurrent.FutureTask.get(Unknown Source) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.NullPointerException at hudson.remoting.ProxyOutputStream$Flush$1.run(ProxyOutputStream.java:305) at hudson.remoting.PipeWriter$1.run(PipeWriter.java:158) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:111) ... 6 more
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
[jclouds-pull-requests #687](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/687/) SUCCESS This pull request looks good --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38475747
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
[jclouds-java-7-pull-requests #1157](https://jclouds.ci.cloudbees.com/job/jclouds-java-7-pull-requests/1157/) SUCCESS This pull request looks good --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38476265
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
[jclouds » jclouds #943](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/943/) 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-38476999
Re: [jclouds-labs-openstack] OS Neutron Extension Router (#47)
Ok the plan is to merge this and then I will be working on it. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-openstack/pull/47#issuecomment-38487773
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
@@ -86,6 +86,16 @@ artifactIdjsch/artifactId scopecompile/scope /dependency +dependency + groupIdcom.jcraft/groupId + artifactIdjsch.agentproxy.jsch/artifactId + version0.0.7/version +/dependency +dependency + groupIdcom.jcraft/groupId + artifactIdjsch.agentproxy.connector-factory/artifactId + version0.0.7/version Thanks for explaining - works for me, then! --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312/files#r10902106
Re: [jclouds-karaf] [JCLOUDS-511] Correcting features with dependency-only bundles (#40)
@iocanel @nacx Do either of you have an opinion on this? I know zilch about Karaf. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-karaf/pull/40#issuecomment-38491152
Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)
@jasdeep-hundal Have you tested this against a DevStack instance that's running both versions of the Glance API? Can you please share your DevStack localrc in a gist? Can you please share the jclouds code in a gist that you ran against a DevStack instance? I'd like to try this in a realish env to help me understand it better. Thanks. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-openstack/pull/82#issuecomment-38492402
[jira] [Commented] (JCLOUDS-512) Cannot start instance from newly created image in ComputeService
[ https://issues.apache.org/jira/browse/JCLOUDS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945871#comment-13945871 ] Ignasi Barrera commented on JCLOUDS-512: If it is a caching problem in the end, I wouldn't make more configurable the cache expiration and such internals (it can be done, but I wouldn't do that to fix this issue). Cache invalidation is quite a sensible topic and it is really hard to reach a proper configuration. If I am not wrong, the images are only modified by the image extension, so we could add the logic to add/evict entries in the cache at that point. Instead of directly calling the extension impl we could change how the image cache is configured so it can be injected in an extension adapter/wrapper that would encapsulate the cache and other common logic and delegate to the provider specific extension. If someone modifies the image list outside the scope of the compute service, we can assume the cache the compute service has can be out of sync. Cannot start instance from newly created image in ComputeService Key: JCLOUDS-512 URL: https://issues.apache.org/jira/browse/JCLOUDS-512 Project: jclouds Issue Type: Bug Components: jclouds-compute Affects Versions: 1.7.1 Reporter: Everett Toews A user found that after they create an image, they cannot start an instance of that image due to it not being found by the TemplateBuilder. See the example code and log in the following gist. https://gist.github.com/everett-toews/5447098 I suspect the images in the TemplateBuilder are being cached and the new one isn't added to that cache but haven't been able to track down the offending code yet. Some notes from IRC for future work: in TemplateBuilderImpl images is Memoized the supplier is in BaseComputeServiceContextModule.supplyImageCache() look at the aws code part of it is EC2TemplateBuilderImpl.lazyImageProvider it is backed by a map which you could listen for and invalidate the image cache entry if the cache interval doesn't work, it is one thing to express an invalidation, well there's a couple ways dig deep and monkey around with internal classes or expose a ListOption.invalidate() and code'in providers to invalidate the cache when they encounter this flag it's not just cache interval, it's PROPERTY_SESSION_INTERVAL. from the name it sounds like if you set it to something low it would invalidate the whole session and reauth, just to invalidate that cache. there's no parameter for the cache probably what would be most helpful is to expose a property that corresponds to CacheBuilderSpec format ex. images.cache-spec=expireAfterWrite=300,refreshInterval=1 pass that in as a property then people can go to town tuning without special casing everything or conflating things like session interval with cache expiry basically, you can see how template is wired in then re-use that approach for the caches the most important one being images so you could skip the others for now -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [jclouds] Delete objects in a container efficiently. (#214)
+ switch (md.getType()) {
+ case BLOB:
+blobDelFuture = executorService.submit(new CallableVoid() {
+ @Override
+ public Void call() {
+ blobStore.removeBlob(containerName, fullPath);
+ return null;
+ }
+ });
+break;
+ case FOLDER:
+if (options.isRecursive()) {
+ blobDelFuture = executorService.submit(new CallableVoid() {
+ @Override
+ public Void call() {
+ blobStore.deleteDirectory(containerName, fullPath);
Previously ```clearContainer``` issued a batch of delete blob operations within
a subtree before removing the parent but now it can issue delete blob
operations concurrently with delete parent. I believe the new logic will
generate operation failures. This is generally a hard problem to solve; can we
simplify this for now by making the recursive call blocking?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/214/files#r10912447
[jira] [Commented] (JCLOUDS-458) Google Cloud Storage support
[ https://issues.apache.org/jira/browse/JCLOUDS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13946174#comment-13946174 ] Andrew Gaul commented on JCLOUDS-458: - [~RoneyThomas] GSoC has an involved matching process: https://www.google-melange.com/gsoc/events/google/gsoc2014 Google Cloud Storage support Key: JCLOUDS-458 URL: https://issues.apache.org/jira/browse/JCLOUDS-458 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Reporter: Andrew Gaul Labels: gsoc2014 Presently users can access Google Cloud Storage via the S3-compatible API, although native support would give access to durable reduced availability, better region support, and resumable uploads. -- This message was sent by Atlassian JIRA (v6.2#6252)
