[jira] [Assigned] (JCLOUDS-1026) Remove public HP cloud compute providers
[ https://issues.apache.org/jira/browse/JCLOUDS-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine reassigned JCLOUDS-1026: -- Assignee: Chris Custine > Remove public HP cloud compute providers > > > Key: JCLOUDS-1026 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1026 > Project: jclouds > Issue Type: Improvement > Components: jclouds-compute >Affects Versions: 2.0.0 >Reporter: Andrew Gaul > Assignee: Chris Custine > Labels: hpcloud-compute > > HP announced that it will sunset its public cloud offering on 31 Jan > > 2016: > > http://h30499.www3.hp.com/t5/Grounded-in-the-Cloud/A-new-model-to-deliver-public-cloud/ba-p/6804409 > We should investigate removing hpcloud-compute and hpcloud-blockstorage > support depending on how HP's private cloud offering evolves. Note that we > plan to remove hpcloud-objectstorage support due to lack of developer > interest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCLOUDS-1026) Remove public HP cloud compute providers
[ https://issues.apache.org/jira/browse/JCLOUDS-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine resolved JCLOUDS-1026. Resolution: Fixed Fix Version/s: 2.0.0 5d82b40d JCLOUDS-1026: Remove public HP cloud compute providers > Remove public HP cloud compute providers > > > Key: JCLOUDS-1026 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1026 > Project: jclouds > Issue Type: Improvement > Components: jclouds-compute >Affects Versions: 2.0.0 >Reporter: Andrew Gaul > Assignee: Chris Custine > Labels: hpcloud-compute > Fix For: 2.0.0 > > > HP announced that it will sunset its public cloud offering on 31 Jan > > 2016: > > http://h30499.www3.hp.com/t5/Grounded-in-the-Cloud/A-new-model-to-deliver-public-cloud/ba-p/6804409 > We should investigate removing hpcloud-compute and hpcloud-blockstorage > support depending on how HP's private cloud offering evolves. Note that we > plan to remove hpcloud-objectstorage support due to lack of developer > interest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jclouds-labs] JCLOUDS-1022: Automatically handle DigitalOcean rate limit (#212)
@nacx This is a great addition and this is quality code. I haven't had time to test but the code looks great and this should be highly useful for DO users. Thanks for doing this. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/212#issuecomment-151024684
Re: [jclouds-labs] JCLOUDS-946: Properly scope images to the locations where they are available (#183)
:+1: Tests run fine for me in several regions and the change looks good. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/183#issuecomment-117297454
[jira] [Commented] (JCLOUDS-613) Implement the DigitalOcean v2 API
[ https://issues.apache.org/jira/browse/JCLOUDS-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14604463#comment-14604463 ] Chris Custine commented on JCLOUDS-613: --- PR Submitted [here|https://github.com/jclouds/jclouds-labs/pull/182] Implement the DigitalOcean v2 API - Key: JCLOUDS-613 URL: https://issues.apache.org/jira/browse/JCLOUDS-613 Project: jclouds Issue Type: New Feature Components: jclouds-compute Affects Versions: 1.7.3 Reporter: Ignasi Barrera Assignee: Ignasi Barrera Labels: digitalocean Fix For: 2.0.0 DigitalOcean has just released the version 2 of their API. It introduces some major changes as long as many improvements and features that make the API more easy to consume. Version 2 is now a more RESTful API, has a better error population (and hope this will help us get rid of the [custom HTTP response parsing code|https://github.com/jclouds/jclouds-labs/blob/master/digitalocean/src/main/java/org/jclouds/digitalocean/http/ResponseStatusFromPayloadHttpCommandExecutorService.java#L89-L128]), and and a more complete domain model. https://www.digitalocean.com/company/blog/api-v2-enters-public-beta/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-613) Implement the DigitalOcean v2 API
[ https://issues.apache.org/jira/browse/JCLOUDS-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14604465#comment-14604465 ] Chris Custine commented on JCLOUDS-613: --- [~nacx] I rebased on master and merged a few pom.xml and generic conflicts from our branches. Resulting branch submitted as the PR is [here|https://github.com/ccustine/jclouds-labs/commit/35c3a3da451575aa093ef8c0560347dc55ae5c49] if you want to take a look. I was able to pass live tests without lengthy timeouts in region FRA1 (which is new and probably less utilized) but still had issues with others. I'm still wondering if we should add the longer timeouts permanently for running tests? WDYT? Implement the DigitalOcean v2 API - Key: JCLOUDS-613 URL: https://issues.apache.org/jira/browse/JCLOUDS-613 Project: jclouds Issue Type: New Feature Components: jclouds-compute Affects Versions: 1.7.3 Reporter: Ignasi Barrera Assignee: Ignasi Barrera Labels: digitalocean Fix For: 2.0.0 DigitalOcean has just released the version 2 of their API. It introduces some major changes as long as many improvements and features that make the API more easy to consume. Version 2 is now a more RESTful API, has a better error population (and hope this will help us get rid of the [custom HTTP response parsing code|https://github.com/jclouds/jclouds-labs/blob/master/digitalocean/src/main/java/org/jclouds/digitalocean/http/ResponseStatusFromPayloadHttpCommandExecutorService.java#L89-L128]), and and a more complete domain model. https://www.digitalocean.com/company/blog/api-v2-enters-public-beta/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-613) Implement the DigitalOcean v2 API
[ https://issues.apache.org/jira/browse/JCLOUDS-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14604429#comment-14604429 ] Chris Custine commented on JCLOUDS-613: --- That would make sense. I was able to get them to pass yesterday with the timeouts increased so I'm not so worried at this point. I'm going to remove them locally and create the PR now. Implement the DigitalOcean v2 API - Key: JCLOUDS-613 URL: https://issues.apache.org/jira/browse/JCLOUDS-613 Project: jclouds Issue Type: New Feature Components: jclouds-compute Affects Versions: 1.7.3 Reporter: Ignasi Barrera Assignee: Ignasi Barrera Labels: digitalocean Fix For: 2.0.0 DigitalOcean has just released the version 2 of their API. It introduces some major changes as long as many improvements and features that make the API more easy to consume. Version 2 is now a more RESTful API, has a better error population (and hope this will help us get rid of the [custom HTTP response parsing code|https://github.com/jclouds/jclouds-labs/blob/master/digitalocean/src/main/java/org/jclouds/digitalocean/http/ResponseStatusFromPayloadHttpCommandExecutorService.java#L89-L128]), and and a more complete domain model. https://www.digitalocean.com/company/blog/api-v2-enters-public-beta/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-613) Implement the DigitalOcean v2 API
[ https://issues.apache.org/jira/browse/JCLOUDS-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14602547#comment-14602547 ] Chris Custine commented on JCLOUDS-613: --- [~nacx]: I have run the live tests many times over the last week and I haven't had a single instance with 100% success. I haven't had much time to dig deeper but most failures seem random (possibly timing issues?), even when running surefire single threaded. Can you confirm that you get consistent success of live tests? I am going to have time Friday to look into this more and hopefully submit the PR if I can figure out what is wrong. Implement the DigitalOcean v2 API - Key: JCLOUDS-613 URL: https://issues.apache.org/jira/browse/JCLOUDS-613 Project: jclouds Issue Type: New Feature Components: jclouds-compute Affects Versions: 1.7.3 Reporter: Ignasi Barrera Assignee: Ignasi Barrera Labels: digitalocean Fix For: 2.0.0 DigitalOcean has just released the version 2 of their API. It introduces some major changes as long as many improvements and features that make the API more easy to consume. Version 2 is now a more RESTful API, has a better error population (and hope this will help us get rid of the [custom HTTP response parsing code|https://github.com/jclouds/jclouds-labs/blob/master/digitalocean/src/main/java/org/jclouds/digitalocean/http/ResponseStatusFromPayloadHttpCommandExecutorService.java#L89-L128]), and and a more complete domain model. https://www.digitalocean.com/company/blog/api-v2-enters-public-beta/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jira] [Commented] (JCLOUDS-613) Implement the DigitalOcean v2 API
I'm going to try these out in a few hours after some sleep. Either way I'll
try to get this pr created tomorrow.
--
Sent from my Android phone
On Jun 26, 2015 2:39 AM, Ignasi Barrera (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/JCLOUDS-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14602569#comment-14602569
]
Ignasi Barrera commented on JCLOUDS-613:
I found the same issue and it is definitely a random timeout issue. It
seems that when you are deploying several nodes, at some point, they start
to boot slower than expected and take their time to boot. I was able to run
the live tests successfully in a consistent way using the following
parameters:
{code}
mvn clean integration-test -Plive \
-Dtest.digitalocean2.identity=unused \
-Dtest.digitalocean2.credential=token \
-Djclouds.compute.timeout.node-terminated=60 \
-Djclouds.compute.timeout.node-running=60 \
-Djclouds.compute.timeout.script-complete=120 \
-Djclouds.compute.timeout.port-open=60 \
-Djclouds.connection-timeout=60 \
-Djclouds.ssh.retry-auth=true
{code}
The point is that the tests that fail are not always the same ones, so the
time it takes a not to boot is not predictable. [~ccustine] can you confirm
that these values work for you? If they work we should add them to the
provider metadata to configure them as defaults.
Let's try to get the PR open soon, as we really want to have a v2
implementation for 1.9.1. Thanks for your feedback!
Implement the DigitalOcean v2 API
-
Key: JCLOUDS-613
URL: https://issues.apache.org/jira/browse/JCLOUDS-613
Project: jclouds
Issue Type: New Feature
Components: jclouds-compute
Affects Versions: 1.7.3
Reporter: Ignasi Barrera
Assignee: Ignasi Barrera
Labels: digitalocean
Fix For: 2.0.0
DigitalOcean has just released the version 2 of their API. It introduces
some major changes as long as many improvements and features that make the
API more easy to consume.
Version 2 is now a more RESTful API, has a better error population (and
hope this will help us get rid of the [custom HTTP response parsing code|
https://github.com/jclouds/jclouds-labs/blob/master/digitalocean/src/main/java/org/jclouds/digitalocean/http/ResponseStatusFromPayloadHttpCommandExecutorService.java#L89-L128]),
and and a more complete domain model.
https://www.digitalocean.com/company/blog/api-v2-enters-public-beta/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-613) Implement the DigitalOcean v2 API
[ https://issues.apache.org/jira/browse/JCLOUDS-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14561763#comment-14561763 ] Chris Custine commented on JCLOUDS-613: --- I'll take a look at this over the weekend and try to fill in the missing tests and fix the remaining issues. Thanks for your help on this [~nacx]! Implement the DigitalOcean v2 API - Key: JCLOUDS-613 URL: https://issues.apache.org/jira/browse/JCLOUDS-613 Project: jclouds Issue Type: New Feature Components: jclouds-compute Affects Versions: 1.7.3 Reporter: Ignasi Barrera Assignee: Ignasi Barrera Labels: digitalocean Fix For: 2.0.0 DigitalOcean has just released the version 2 of their API. It introduces some major changes as long as many improvements and features that make the API more easy to consume. Version 2 is now a more RESTful API, has a better error population (and hope this will help us get rid of the [custom HTTP response parsing code|https://github.com/jclouds/jclouds-labs/blob/master/digitalocean/src/main/java/org/jclouds/digitalocean/http/ResponseStatusFromPayloadHttpCommandExecutorService.java#L89-L128]), and and a more complete domain model. https://www.digitalocean.com/company/blog/api-v2-enters-public-beta/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-613) Implement the DigitalOcean v2 API
[ https://issues.apache.org/jira/browse/JCLOUDS-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14529527#comment-14529527 ] Chris Custine commented on JCLOUDS-613: --- This sounds like a great plan. I just rebased on master and ran live tests with all upstream jclouds changes and have 2 new failures since last time I ran them I will take a look at those, but other than that, everything seems to be working great. I will also take a look at the API changes and see if anything needs to be updated/added. Implement the DigitalOcean v2 API - Key: JCLOUDS-613 URL: https://issues.apache.org/jira/browse/JCLOUDS-613 Project: jclouds Issue Type: New Feature Components: jclouds-compute Affects Versions: 1.7.3 Reporter: Ignasi Barrera Assignee: Ignasi Barrera Labels: digitalocean Fix For: 2.0.0 DigitalOcean has just released the version 2 of their API. It introduces some major changes as long as many improvements and features that make the API more easy to consume. Version 2 is now a more RESTful API, has a better error population (and hope this will help us get rid of the [custom HTTP response parsing code|https://github.com/jclouds/jclouds-labs/blob/master/digitalocean/src/main/java/org/jclouds/digitalocean/http/ResponseStatusFromPayloadHttpCommandExecutorService.java#L89-L128]), and and a more complete domain model. https://www.digitalocean.com/company/blog/api-v2-enters-public-beta/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-613) Implement the DigitalOcean v2 API
[ https://issues.apache.org/jira/browse/JCLOUDS-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14527043#comment-14527043 ] Chris Custine commented on JCLOUDS-613: --- [~nacx] I have about 99% of this done here: https://github.com/ccustine/jclouds-labs/tree/features/digitalocean2final The parts missing are paged iterables for lists, and I need to check the few API changes they made while in Beta since January. I have very few cycles at the moment so perhaps we could work together to finish this off? From what I can tell, there is very little to be done to get this up to the final v2 release API level, and then adding the paged iterables to finish it off. Implement the DigitalOcean v2 API - Key: JCLOUDS-613 URL: https://issues.apache.org/jira/browse/JCLOUDS-613 Project: jclouds Issue Type: New Feature Components: jclouds-compute Affects Versions: 1.7.3 Reporter: Ignasi Barrera Assignee: Ignasi Barrera Labels: digitalocean Fix For: 2.0.0 DigitalOcean has just released the version 2 of their API. It introduces some major changes as long as many improvements and features that make the API more easy to consume. Version 2 is now a more RESTful API, has a better error population (and hope this will help us get rid of the [custom HTTP response parsing code|https://github.com/jclouds/jclouds-labs/blob/master/digitalocean/src/main/java/org/jclouds/digitalocean/http/ResponseStatusFromPayloadHttpCommandExecutorService.java#L89-L128]), and and a more complete domain model. https://www.digitalocean.com/company/blog/api-v2-enters-public-beta/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jclouds] Fix rackspace volume attach with modernized base tests (#710)
@nacx @everett-toews @zack-shoylev I am delivering a project this week so I have been heads down crunching on that, but to be honest I don't totally understand the issue as it related to HP Cloud. HPs nova supports os-volumes extension and IIRC cinder already has the attachment support baked in. Let me know if I am wrong about that, and specifically let me know if there is any specific test you want me to run and report. I tried to run the tests against RC1 and I had failures for other (unrelated) issues so it seems. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/710#issuecomment-84948440
Re: [jclouds] Deprecate Nova API for volumes in favour of Cinder API for volumes (#708)
:+1: HP provider has full Cinder support and is well tested. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/708#issuecomment-83618242
[jira] [Closed] (JCLOUDS-408) JClouds(HPCloud): Server list fails with JSON error.
[ https://issues.apache.org/jira/browse/JCLOUDS-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine closed JCLOUDS-408. - Resolution: Fixed Fix Version/s: 1.8.0 Assignee: Chris Custine This was fixed in 1.8.0. JClouds(HPCloud): Server list fails with JSON error. Key: JCLOUDS-408 URL: https://issues.apache.org/jira/browse/JCLOUDS-408 Project: jclouds Issue Type: Bug Components: jclouds-compute Affects Versions: 1.6.2 Reporter: uma maheswari mohandoss Assignee: Chris Custine Labels: hpcloud-compute Fix For: 1.8.0 JClouds - HPCloud. JClouds version tried: 1.6.1, 16.2, 1.6.2-incubating. List server fails when there is a VM booted from volume. Consider VM that is booted from volume, this VM is then listed by fetching list from servers/details - such server has no image. However in JSON response image is returned as empty string. Finally resulting in JSON error. Note: If server list DOES NOT contain VM booted from volume, NOT hitting this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (JCLOUDS-407) JClouds (HPCloud) documentation is not upto date
[ https://issues.apache.org/jira/browse/JCLOUDS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine closed JCLOUDS-407. - Resolution: Fixed Fix Version/s: 1.8.0 Assignee: Chris Custine I'm closing this because the HP Cloud documentation was updated for 1.8.0 and is still current. I didn't notice this older issue about docs at the time. JClouds (HPCloud) documentation is not upto date Key: JCLOUDS-407 URL: https://issues.apache.org/jira/browse/JCLOUDS-407 Project: jclouds Issue Type: Improvement Components: docs Affects Versions: 1.6.2 Reporter: uma maheswari mohandoss Assignee: Chris Custine Fix For: 1.8.0 The documentation needs an update according to the latest jclouds version. It would seem that a new user who just followed instructions on JClouds website and tried to run simplest example they have would fail miserably to achieve anything. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (JCLOUDS-809) Launching jclouds interactive CLI does not display output
[
https://issues.apache.org/jira/browse/JCLOUDS-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Custine reassigned JCLOUDS-809:
-
Assignee: Chris Custine
Launching jclouds interactive CLI does not display output
-
Key: JCLOUDS-809
URL: https://issues.apache.org/jira/browse/JCLOUDS-809
Project: jclouds
Issue Type: Bug
Components: jclouds-cli
Affects Versions: 1.9.0
Reporter: Andrew Gaul
Assignee: Chris Custine
Fix For: 1.9.0
Launching does not show a prompt:
{noformat}
$ jclouds-cli-2.0.0-SNAPSHOT/bin/jclouds-cli
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (JCLOUDS-675) Upgrade CLI to Karaf 3.0
[ https://issues.apache.org/jira/browse/JCLOUDS-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine closed JCLOUDS-675. - Upgrade CLI to Karaf 3.0 Key: JCLOUDS-675 URL: https://issues.apache.org/jira/browse/JCLOUDS-675 Project: jclouds Issue Type: Improvement Components: jclouds-cli, jclouds-karaf Affects Versions: 1.8.0 Reporter: Chris Custine Assignee: Chris Custine Karaf 2.3.x is not going to be compatible with JRE 1.8 due to lack of support in 3rd party bundles such as ASM and Aries. jclouds 2.0 is probably a good release to target an upgrade to Karaf 3.0 which packages new versions of the required bundles with JRE 1.8 support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCLOUDS-675) Upgrade CLI to Karaf 3.0
[ https://issues.apache.org/jira/browse/JCLOUDS-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine resolved JCLOUDS-675. --- Resolution: Won't Fix According to my testing, later versions of Karaf 2.3 work fine with Java 8 so I am closing this as won't fix. We might still upgrade to Karaf 3 or 4 before the next release but I will create a new issue if necessary. Upgrade CLI to Karaf 3.0 Key: JCLOUDS-675 URL: https://issues.apache.org/jira/browse/JCLOUDS-675 Project: jclouds Issue Type: Improvement Components: jclouds-cli, jclouds-karaf Affects Versions: 1.8.0 Reporter: Chris Custine Assignee: Chris Custine Karaf 2.3.x is not going to be compatible with JRE 1.8 due to lack of support in 3rd party bundles such as ASM and Aries. jclouds 2.0 is probably a good release to target an upgrade to Karaf 3.0 which packages new versions of the required bundles with JRE 1.8 support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (JCLOUDS-673) jclouds-cli interactive mode does not have any commands
[
https://issues.apache.org/jira/browse/JCLOUDS-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Custine closed JCLOUDS-673.
-
Resolution: Fixed
Fixed by upgrading Karaf to 2.3.9 (latest 2.3.x available) and syncing
dependencies according to [the Karaf dependency
matrix|http://karaf.apache.org/index/documentation/karaf-dependencies/karaf-deps-2.3.x.html].
This was probably solved already but I will mark it closed as I have verified
all commands are present now.
jclouds-cli interactive mode does not have any commands
---
Key: JCLOUDS-673
URL: https://issues.apache.org/jira/browse/JCLOUDS-673
Project: jclouds
Issue Type: Bug
Components: jclouds-cli
Affects Versions: 1.8.0
Reporter: Andrew Gaul
Assignee: Chris Custine
Fix For: 1.9.0
Attachments: jclouds-cli.txt
Upon launching, several errors of the form:
{noformat}
ERROR: Bundle org.apache.jclouds.karaf.core [51] Error starting
mvn:org.apache.jclouds.karaf/core/1.8.0 (org.osgi.framework.BundleException:
Unresolved constraint in bundle org.apache.jclouds.karaf.core [51]: Unable to
resolve 51.0: missing requirement [51.0] package;
((package=org.osgi.framework)(version=1.6.0)))
org.osgi.framework.BundleException: Unresolved constraint in bundle
org.apache.jclouds.karaf.core [51]: Unable to resolve 51.0: missing
requirement [51.0] package; ((package=org.osgi.framework)(version=1.6.0))
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3446)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1734)
at
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1163)
at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:745)
{noformat}
No jclouds commands found:
{noformat}
jclouds blobstore-container-list
Command not found: blobstore-container-list
{noformat}
Note that non-interactive mode works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (JCLOUDS-674) jclouds-cli interactive mode does not work with Java 8
[
https://issues.apache.org/jira/browse/JCLOUDS-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Custine closed JCLOUDS-674.
-
Resolution: Fixed
Fixed by upgrading Karaf to 2.3.9 (latest 2.3.x available) and syncing
dependencies according to [the Karaf dependency
matrix|http://karaf.apache.org/index/documentation/karaf-dependencies/karaf-deps-2.3.x.html].
I can't find any issues with Java 8 using Karaf 2.3.9 but I am not sure Java 8
support is official. I will be looking at an upgrade to Karaf 3 or 4 which
officially support Java 8 in the future, but those will not be trivial upgrades.
jclouds-cli interactive mode does not work with Java 8
--
Key: JCLOUDS-674
URL: https://issues.apache.org/jira/browse/JCLOUDS-674
Project: jclouds
Issue Type: Bug
Components: jclouds-cli
Affects Versions: 1.8.0
Reporter: Andrew Gaul
Assignee: Chris Custine
Fix For: 1.9.0
Refuses to launch with:
{noformat}
Could not create framework: java.lang.ArrayIndexOutOfBoundsException: -1
java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(ArrayList.java:403)
at java.util.ArrayList.get(ArrayList.java:416)
at
org.apache.felix.framework.BundleImpl.getCurrentModule(BundleImpl.java:1050)
at
org.apache.felix.framework.BundleImpl.getSymbolicName(BundleImpl.java:859)
at org.apache.felix.framework.Felix.toString(Felix.java:1019)
at org.apache.felix.framework.Logger.doLog(Logger.java:128)
at org.apache.felix.framework.Logger._log(Logger.java:181)
at org.apache.felix.framework.Logger.log(Logger.java:114)
at
org.apache.felix.framework.ExtensionManager.init(ExtensionManager.java:201)
at org.apache.felix.framework.Felix.init(Felix.java:374)
at
org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:28)
at org.apache.karaf.main.Main.launch(Main.java:268)
at org.apache.karaf.main.Main.main(Main.java:429)
{noformat}
Note that non-interactive mode works. Related to JCLOUDS-673?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (JCLOUDS-809) Launching jclouds interactive CLI does not display output
[
https://issues.apache.org/jira/browse/JCLOUDS-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Custine closed JCLOUDS-809.
-
Resolution: Fixed
Fixed by upgrading Karaf to 2.3.9 (latest 2.3.x available) and syncing
dependencies according to [the Karaf dependency
matrix|http://karaf.apache.org/index/documentation/karaf-dependencies/karaf-deps-2.3.x.html].
Launching jclouds interactive CLI does not display output
-
Key: JCLOUDS-809
URL: https://issues.apache.org/jira/browse/JCLOUDS-809
Project: jclouds
Issue Type: Bug
Components: jclouds-cli
Affects Versions: 1.9.0
Reporter: Andrew Gaul
Assignee: Chris Custine
Fix For: 1.9.0
Launching does not show a prompt:
{noformat}
$ jclouds-cli-2.0.0-SNAPSHOT/bin/jclouds-cli
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (JCLOUDS-790) hpcloud-objectstorage to use openstack-swift
[ https://issues.apache.org/jira/browse/JCLOUDS-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine reassigned JCLOUDS-790: - Assignee: Chris Custine hpcloud-objectstorage to use openstack-swift Key: JCLOUDS-790 URL: https://issues.apache.org/jira/browse/JCLOUDS-790 Project: jclouds Issue Type: Improvement Components: jclouds-blobstore Reporter: Everett Toews Assignee: Chris Custine Fix For: 2.0.0 hpcloud-objectstorage needs to use openstack-swift for us to be able to remove the deprecated swift api -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (JCLOUDS-111) hpcloud-compute - Error while setting strRegion - region-b.geo-1 (a new region)
[
https://issues.apache.org/jira/browse/JCLOUDS-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Custine closed JCLOUDS-111.
-
Resolution: Fixed
Fix Version/s: 1.8.0
hpcloud-compute - Error while setting strRegion - region-b.geo-1 (a new
region)
---
Key: JCLOUDS-111
URL: https://issues.apache.org/jira/browse/JCLOUDS-111
Project: jclouds
Issue Type: Bug
Components: jclouds-compute
Affects Versions: 1.5.10
Environment: hpcloud-compute
Reporter: Ravikumar Venkatesan
Assignee: Chris Custine
Fix For: 1.8.0
I have set strRegion - region-b.geo-1 (a new region) for hpcloud-compute
provider, and while running get the following errror.
Exception in thread main java.lang.IllegalArgumentException: requested
location region-b.geo-1, which is not in the configured locations:
{az-1.region-a.geo-1=Suppliers.ofInstance(https://az-1.region-a.geo-1.compute.hpcloudsvc.com/v1.1/),
az-2.region-a.geo-1=Suppliers.ofInstance(https://az-2.region-a.geo-1.compute.hpcloudsvc.com/v1.1/),
az-3.region-a.geo-1=Suppliers.ofInstance(https://az-3.region-a.geo-1.compute.hpcloudsvc.com/v1.1/)}
at
com.google.common.base.Preconditions.checkArgument(Preconditions.java:119)
at
org.jclouds.location.functions.ZoneToEndpoint.apply(ZoneToEndpoint.java:56)
at
org.jclouds.location.functions.ZoneToEndpoint.apply(ZoneToEndpoint.java:41)
at
org.jclouds.rest.internal.RestAnnotationProcessor.getEndpointInParametersOrNull(RestAnnotationProcessor.java:705)
at
org.jclouds.rest.internal.RestAnnotationProcessor.getEndpointFor(RestAnnotationProcessor.java:741)
at
org.jclouds.rest.internal.RestAnnotationProcessor.findEndpoint(RestAnnotationProcessor.java:565)
at
org.jclouds.rest.internal.RestAnnotationProcessor.createRequest(RestAnnotationProcessor.java:386)
at
org.jclouds.rest.internal.AsyncRestClientProxy.createListenableFutureForHttpRequestMappedToMethodAndArgs(AsyncRestClientProxy.java:243)
at
org.jclouds.rest.internal.AsyncRestClientProxy.invoke(AsyncRestClientProxy.java:148)
at $Proxy79.listInDetail(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jclouds.concurrent.internal.SyncProxy.invoke(SyncProxy.java:170)
at $Proxy80.listInDetail(Unknown Source)
at hpcsCompute.main(hpcsCompute.java:56)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (JCLOUDS-238) api/openstack-compute supports only a per AZ deployment model
[
https://issues.apache.org/jira/browse/JCLOUDS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Custine closed JCLOUDS-238.
-
Resolution: Fixed
Fix Version/s: 1.8.0
As of 1.8.0 (fixed in issue JCLOUDS-647) you retrieve the api for a region with
getServerApi(region_name) on NovaApi. If necessary, you can specify an
availability zone with NovaTemplateOptions.availabilityZone(az3), etc.
api/openstack-compute supports only a per AZ deployment model
-
Key: JCLOUDS-238
URL: https://issues.apache.org/jira/browse/JCLOUDS-238
Project: jclouds
Issue Type: Bug
Components: jclouds-compute
Affects Versions: 1.6.0
Reporter: Kavan K Patil
Assignee: Chris Custine
Fix For: 1.8.0
I have been testing NovaApi against HP Cloud and have been working with both
per AZ endpoint model and a region wide endpoint model in different regions.
For clarity I would define the following two terms so that it helps me
providing further details:
Per AZ endpoint model : I call it so as we get a per AZ compute endpoint url.
Using this URL we could only work with a particular AZ of a cloud provider
(e.g. HP Cloud region-a has az1.region-a.geo-1 as one AZ and has its own
compute endpoint)
Region wide endpoint model: In this model there will be one compute endpoint
exposed by the provider. But underneath there could be multiple AZs. All the
openstack services work region wide and compute instances can be placed on
all AZs within the region selectively through an option while creating
instances. (e.g. HPCloud region-b.geo-1, which will have a single endpoint
for compute for the entire region. This is still in private beta stage.)
The existing framework with JClouds doesn't seem to fit the region wide model
and below I describe 3 issues I see.
To start with I can create a single connection for HP Cloud as below
{code}
---
NovaApi api =
ContextBuilder.newBuilder(hpcloud-compute)
.credentials(identity, password)
.modules(modules)
.apiVersion(2) //The api version of region-b.geo-1 is 2
which is required for next steps
-
{code}
And the issues:
1. But to get a reference to the ServerApi under this region I need to give
the name of a region, though the method name clearly expects a zone id.
{code}
-
//So now we have a new connection to region-b-geo-1
//But to get a ServerApi handle I need to do
//This looks ugly, as i need to provide the name of region for a zone!
serverApi = this.novaApi.getServerApiForZone(region-b.geo-1);
//Ideally one should be able to do this instead of the above. But JClouds
throws an error that an endpoint for this AZ was not found
//serverApi = this.novaApi.getServerApiForZone(az1);
--
{code}
2. Also now that I have a ServerApi to the region, I don't get to select an
AZ to schedule an instance to a specific one. There is NO option under
CreateServerOptions to specify an AZ name!
3. And the below call should return all AZs (az1, az2, az3), but it only
returns region-b.geo-1
{code}
-
this.novaApi.getConfiguredZones()
-
{code}
I think this is due to the fact that the implementation of
getConfiguredZones() is mapped to the endpoints in the service catalogue
rather than the below API extension:
{code}
curl -i
https://region-b.geo-1.compute.hpcloudsvc.com/v2/tenant-id/os-availability-zone
-X GET -H Accept: application/json -H X-Auth-Token: token
RESP: [200] CaseInsensitiveDict({'date': 'Mon, 05 Aug 2013 10:35:03 GMT',
'content-length': '236', 'content-type': 'application/json',
'x-compute-request-id': 'req-c19dcfba-8a21-4a7e-b463-19943267c9bb'})
RESP BODY: {availabilityZoneInfo: [{zoneState: {available: true},
hosts: null, zoneName: az1}, {zoneState: {available: true},
hosts: null, zoneName: az2}, {zoneState: {available: true},
hosts: null, zoneName: az3}]}
--
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-518) Support retrieving OAuth tokens from GCE instance metadata
[ https://issues.apache.org/jira/browse/JCLOUDS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215575#comment-14215575 ] Chris Custine commented on JCLOUDS-518: --- Since each instance gets a new token and the metadata is only visible to the instance, I'm not sure how we would do this. If you have a use case and possibly some way to get that token via the public API we could see about adding it but I am not so sure. Support retrieving OAuth tokens from GCE instance metadata -- Key: JCLOUDS-518 URL: https://issues.apache.org/jira/browse/JCLOUDS-518 Project: jclouds Issue Type: New Feature Components: jclouds-labs-google Affects Versions: 1.7.1 Reporter: MikoĊaj Zalewski Assignee: Chris Custine Priority: Minor If configured, a GCE instance has access to an OAuth token for the project's service account. It's available through the http://metadata server. The details are described in https://developers.google.com/compute/docs/authentication . This feature request is to provide an API to retrieve this token. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jclouds-labs-google] Refactor OAuth so that it doesn't require private keys when we aren't signing anything (#90)
+1 Its been a bit of a moving target anyway :-) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/90#issuecomment-62635337
Re: [jclouds-labs-google] Removed the need for users to manually specify the current project name. (#88)
+1 @adriancole I missed where/what the default project name is set. I assume it is empty but I couldn't find it. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/88#issuecomment-62417142
Re: [jclouds-labs-google] Consolidate operation state management. (#83)
I checked this all out last night but forgot to +1 it. LGTM, and I will take a look at these last 3 tests today when I get a chance. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/83#issuecomment-62173651
[jclouds-labs-google] Support reading key from file (#84)
You can merge this Pull Request by running: git pull https://github.com/ccustine/jclouds-labs-google features/fixes Or you can view, comment on it, or merge it online at: https://github.com/jclouds/jclouds-labs-google/pull/84 -- Commit Summary -- * Misc fixes to support file based key and bearer tokens -- File Changes -- M google-cloud-storage/src/test/java/org/jclouds/googlecloudstorage/internal/BaseGoogleCloudStorageApiExpectTest.java (1) M google-compute-engine/src/test/java/org/jclouds/googlecomputeengine/internal/BaseGoogleComputeEngineApiExpectTest.java (1) M oauth/src/main/java/org/jclouds/oauth/v2/OAuthApiMetadata.java (3) M oauth/src/main/java/org/jclouds/oauth/v2/filters/BearerTokenAuthenticator.java (2) M oauth/src/main/java/org/jclouds/oauth/v2/functions/OAuthCredentialsSupplier.java (33) M oauth/src/test/java/org/jclouds/oauth/v2/OAuthTestUtils.java (4) M oauth/src/test/java/org/jclouds/oauth/v2/functions/OAuthCredentialsFromPKTest.java (3) M oauth/src/test/java/org/jclouds/oauth/v2/functions/OAuthCredentialsSupplierTest.java (7) -- Patch Links -- https://github.com/jclouds/jclouds-labs-google/pull/84.patch https://github.com/jclouds/jclouds-labs-google/pull/84.diff --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/84
Re: [jclouds-labs-google] Support reading key from file (#84)
You are right about the file io. Part of this is still necessary to use oauth bearer tokens outside of the google providers so I will kill this and start another PR with this code whittled down. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/84#issuecomment-62230551
Re: [jclouds-labs-google] Support reading key from file (#84)
Closed #84. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/84#event-190228524
[jclouds-labs-google] Fix support for bearer tokens (#85)
You can merge this Pull Request by running: git pull https://github.com/ccustine/jclouds-labs-google features/fixes Or you can view, comment on it, or merge it online at: https://github.com/jclouds/jclouds-labs-google/pull/85 -- Commit Summary -- * Fix support for bearer tokens -- File Changes -- M oauth/src/main/java/org/jclouds/oauth/v2/OAuthApiMetadata.java (5) M oauth/src/main/java/org/jclouds/oauth/v2/filters/BearerTokenAuthenticator.java (2) M oauth/src/main/java/org/jclouds/oauth/v2/functions/OAuthCredentialsSupplier.java (15) M oauth/src/test/java/org/jclouds/oauth/v2/OAuthTestUtils.java (4) M oauth/src/test/java/org/jclouds/oauth/v2/functions/OAuthCredentialsFromPKTest.java (3) M oauth/src/test/java/org/jclouds/oauth/v2/functions/OAuthCredentialsSupplierTest.java (7) -- Patch Links -- https://github.com/jclouds/jclouds-labs-google/pull/85.patch https://github.com/jclouds/jclouds-labs-google/pull/85.diff --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/85
Re: [jclouds] JCLOUDS-750 Revert customizing FieldNamingStrategy in favor of tighter contract on @SerializedNames. (#596)
+1 This will make things much better :) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/596#issuecomment-61376316
Re: [jclouds-labs] JCLOUDS-750 FieldNamingStrategy is no longer required. (#108)
+1 --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/108#issuecomment-61378465
[jclouds-karaf] Downgrade guava to be in sync with 2.0.0-SNAPSHOT bundles (#59)
You can merge this Pull Request by running: git pull https://github.com/ccustine/jclouds-karaf fixes/guava16 Or you can view, comment on it, or merge it online at: https://github.com/jclouds/jclouds-karaf/pull/59 -- Commit Summary -- * Downgrade guava to be in sync with 2.0.0-SNAPSHOT bundles -- File Changes -- M commands/src/main/java/org/jclouds/karaf/commands/blobstore/BlobReadCommand.java (4) M pom.xml (2) -- Patch Links -- https://github.com/jclouds/jclouds-karaf/pull/59.patch https://github.com/jclouds/jclouds-karaf/pull/59.diff --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-karaf/pull/59
Re: [jclouds-karaf] Downgrade guava to be in sync with 2.0.0-SNAPSHOT bundles (#59)
@nacx This should solve the test issues you are seeing in #58 --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-karaf/pull/59#issuecomment-61062448
Re: [jclouds-labs-google] At the cost of fiddling with type hierarchy adapters, remove lots of junk with google auto (#67)
+1 I haven't tested with WIP such as the DO v2 API but the code looks good. After seeing some of this Autovalue stuff, I am going to switch the DO v2 provider to use it ASAP :-) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/67#issuecomment-60615645
Re: [jclouds-labs-google] Revert JCLOUDS-653: Address Guava 18 deprecations (#63)
+1 LGTM --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/63#issuecomment-60411474
Re: [jclouds] Upgrade assertj-core to 1.7.0 (#579)
+1 --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/579#issuecomment-60432107
Re: [jclouds-labs] Cleanup round 1 of azurecompute: Output value types. (#92)
+1 btw, what are we waiting on before using autovalue? A specific issue or feature? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/92#issuecomment-59810657
[jira] [Resolved] (JCLOUDS-495) GCE provider default template not picking an image
[ https://issues.apache.org/jira/browse/JCLOUDS-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine resolved JCLOUDS-495. --- Resolution: Fixed Fix Version/s: 1.8.0 2.0.0 GCE provider default template not picking an image -- Key: JCLOUDS-495 URL: https://issues.apache.org/jira/browse/JCLOUDS-495 Project: jclouds Issue Type: Bug Components: jclouds-labs-google Affects Versions: 1.7.1 Reporter: Suriya priya Veluchamy Assignee: Chris Custine Priority: Minor Fix For: 2.0.0, 1.8.0 TemplateBuilder templateBuilder = compute.templateBuilder(); After changing [1] to make use of GCE, compute.createNodesInGroup(groupName, 1, templateBuilder.build())) - is failing with below error. adding node to group mygroup error: no image matched predicate: And(nullEqualToIsParentOrIsGrandparentOfCurrentLocation(),And(osFamily(gcel),osVersion(1[012].[01][04]))) [2] is the relevant email. [1] https://github.com/jclouds/jclouds-examples/blob/master/compute-basics/src/main/java/org/jclouds/examples/compute/basics/MainApp.java [2] http://www.mail-archive.com/dev@jclouds.apache.org/msg04413.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-495) GCE provider default template not picking an image
[ https://issues.apache.org/jira/browse/JCLOUDS-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14173833#comment-14173833 ] Chris Custine commented on JCLOUDS-495: --- [~broudy] Yeah this is was resolved, I forgot to update the issue. Marking as resolved now. GCE provider default template not picking an image -- Key: JCLOUDS-495 URL: https://issues.apache.org/jira/browse/JCLOUDS-495 Project: jclouds Issue Type: Bug Components: jclouds-labs-google Affects Versions: 1.7.1 Reporter: Suriya priya Veluchamy Assignee: Chris Custine Priority: Minor Fix For: 1.8.0, 2.0.0 TemplateBuilder templateBuilder = compute.templateBuilder(); After changing [1] to make use of GCE, compute.createNodesInGroup(groupName, 1, templateBuilder.build())) - is failing with below error. adding node to group mygroup error: no image matched predicate: And(nullEqualToIsParentOrIsGrandparentOfCurrentLocation(),And(osFamily(gcel),osVersion(1[012].[01][04]))) [2] is the relevant email. [1] https://github.com/jclouds/jclouds-examples/blob/master/compute-basics/src/main/java/org/jclouds/examples/compute/basics/MainApp.java [2] http://www.mail-archive.com/dev@jclouds.apache.org/msg04413.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jclouds-labs-google] JCLOUDS-649: Added image creation from pd, changed rawDisk to OptionalT (#59)
@danbroudy Aside from the comment from @nacx about the System.out in that test, everything LGTM. I think if you fix that, rebase and squash to a single commit, I will +1 and merge this in. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/59#issuecomment-59376447
[jira] [Updated] (JCLOUDS-613) Implement the DigitalOcean v2 API
[ https://issues.apache.org/jira/browse/JCLOUDS-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine updated JCLOUDS-613: -- Assignee: Chris Custine (was: Ignasi Barrera) Implement the DigitalOcean v2 API - Key: JCLOUDS-613 URL: https://issues.apache.org/jira/browse/JCLOUDS-613 Project: jclouds Issue Type: New Feature Components: jclouds-compute Affects Versions: 1.7.3 Reporter: Ignasi Barrera Assignee: Chris Custine Labels: digitalocean Fix For: 2.0.0 DigitalOcean has just released the version 2 of their API. It introduces some major changes as long as many improvements and features that make the API more easy to consume. Version 2 is now a more RESTful API, has a better error population (and hope this will help us get rid of the [custom HTTP response parsing code|https://github.com/jclouds/jclouds-labs/blob/master/digitalocean/src/main/java/org/jclouds/digitalocean/http/ResponseStatusFromPayloadHttpCommandExecutorService.java#L89-L128]), and and a more complete domain model. https://www.digitalocean.com/company/blog/api-v2-enters-public-beta/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jclouds-labs-google] JCLOUDS-649: Added image creation from pd, changed rawDisk to OptionalT (#59)
@danbroudy Yeah it is perfectly fine to change the return type here in a labs project. If we had released this before the PR, then we would have to wait until 2.0, so this worked out nicely. I don't have time to review this in detail but I'll be back with a review in a couple of hours. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/59#issuecomment-59300182
Re: [jclouds] fix support for private images in SoftLayer (#568)
:+1: LGTM --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/568#issuecomment-59127997
[jira] [Commented] (JCLOUDS-747) Determine level of android support and how to ensure we keep it.
[
https://issues.apache.org/jira/browse/JCLOUDS-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168851#comment-14168851
]
Chris Custine commented on JCLOUDS-747:
---
I agree that we should at least stop the door from slamming on potential
Android development even if we have nothing concrete going right now. I know
several people on the project have talked about wanting to work on this for
some time now, so I think we should give it a fighting chance. As I said in my
email, I think this subject is fairly well documented wrt language features and
sdk versions so it shouldn't be too difficult to draw up some guidelines on
maintaining Android compatibility.
Determine level of android support and how to ensure we keep it.
Key: JCLOUDS-747
URL: https://issues.apache.org/jira/browse/JCLOUDS-747
Project: jclouds
Issue Type: Improvement
Components: jclouds-core
Reporter: Adrian Cole
One of the knock-on effects of moving on is tracking how we deal with
android. One way is to establish a floor android level we aim to support
(even if it is best efforts). That's due to the fact that android != java and
only a subset of features are present, on each version. Here's a handy link
that begins to discuss this complexity.
http://stackoverflow.com/questions/20480090/does-android-support-jdk-6-or-7
Modern android libraries typically use a combination of plugins and
integration tests to ensure android isn't accidentally broken. Some projects
just rely on folks to remember the rules.
Here's an example of a signature-checking plugin
{code}
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdanimal-sniffer-maven-plugin/artifactId
version${animal.sniffer.version}/version
executions
execution
phasetest/phase
goals
goalcheck/goal
/goals
/execution
/executions
configuration
signature
groupIdorg.codehaus.mojo.signature/groupId
artifactIdjava16/artifactId
version1.1/version
/signature
/configuration
/plugin
{code}
In short, I think we should be careful and consciously decide whether certain
features that break some level of android support are worthwhile. We should
also note that entrypoints that aren't used by android callers will not
affect compatibility. In other words, we are most concerned with the common
paths.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [jclouds] remove io executor (#554)
+1 --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/554#issuecomment-58025904
Re: [jclouds-labs-google] unasync Fallback. (#55)
+1 LGTM --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/55#issuecomment-58097415
Re: [jclouds-labs-google] JCLOUDS-703 missing imageSpaceGb from machineType (#49)
+1 I'm going to merge this in after confirming with Google that imageSpaceGb is going to be missing for now, but may return later. Only safe thing to do is ignore it for image selection. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/49#issuecomment-58099450
[jira] [Assigned] (JCLOUDS-703) Google Hardware no longer supports images
[
https://issues.apache.org/jira/browse/JCLOUDS-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Custine reassigned JCLOUDS-703:
-
Assignee: Chris Custine
Google Hardware no longer supports images
-
Key: JCLOUDS-703
URL: https://issues.apache.org/jira/browse/JCLOUDS-703
Project: jclouds
Issue Type: Bug
Components: jclouds-labs-google
Affects Versions: 1.8.0
Environment: Java 1.8
Reporter: Stuart Hendren
Assignee: Chris Custine
Priority: Critical
Fix For: 1.8.1, 2.0.0
All Google hardware now has the AlwaysFalse predicate for supportsImage().
This seems to be because the response for MachineType is missing a value for
imageSpaceGb, which gets assigned 0 in the MachineType class and this
results in the AlwaysFalse predicate.
Current example machine type return taken from a response to GET
https://www.googleapis.com/compute/v1/projects/project/zones/zone/machineTypes:
{noformat}
{
kind: compute#machineType,
id: 7224129552184485774,
creationTimestamp: 2013-04-25T13:32:45.550-07:00,
name: g1-small,
description: 1 vCPU (shared physical core) and 1.7 GB RAM,
guestCpus: 1,
memoryMb: 1740,
maximumPersistentDisks: 4,
maximumPersistentDisksSizeGb: 3072,
zone: europe-west1-a,
selfLink:
https://www.googleapis.com/compute/v1/projects/cold-front/zones/europe-west1-a/machineTypes/g1-small;
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [jclouds-labs-google] JCLOUDS-703 missing imageSpaceGb from machineType (#49)
Thanks @stuarthendren , rebased and merged as below. Merged to master [here](https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=65ac580) Backported to 1.8.x [here](https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=4e068d5) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/49#issuecomment-58106327
[jira] [Closed] (JCLOUDS-703) Google Hardware no longer supports images
[
https://issues.apache.org/jira/browse/JCLOUDS-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Custine closed JCLOUDS-703.
-
Resolution: Fixed
Thanks for the patch Stuart.
Google Hardware no longer supports images
-
Key: JCLOUDS-703
URL: https://issues.apache.org/jira/browse/JCLOUDS-703
Project: jclouds
Issue Type: Bug
Components: jclouds-labs-google
Affects Versions: 1.8.0
Environment: Java 1.8
Reporter: Stuart Hendren
Assignee: Chris Custine
Priority: Critical
Fix For: 1.8.1, 2.0.0
All Google hardware now has the AlwaysFalse predicate for supportsImage().
This seems to be because the response for MachineType is missing a value for
imageSpaceGb, which gets assigned 0 in the MachineType class and this
results in the AlwaysFalse predicate.
Current example machine type return taken from a response to GET
https://www.googleapis.com/compute/v1/projects/project/zones/zone/machineTypes:
{noformat}
{
kind: compute#machineType,
id: 7224129552184485774,
creationTimestamp: 2013-04-25T13:32:45.550-07:00,
name: g1-small,
description: 1 vCPU (shared physical core) and 1.7 GB RAM,
guestCpus: 1,
memoryMb: 1740,
maximumPersistentDisks: 4,
maximumPersistentDisksSizeGb: 3072,
zone: europe-west1-a,
selfLink:
https://www.googleapis.com/compute/v1/projects/cold-front/zones/europe-west1-a/machineTypes/g1-small;
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [jclouds] Moved jclouds-chef to the main repo (#536)
+relativePath../../project/pom.xml/relativePath
+ /parent
+ groupIdorg.apache.jclouds.api/groupId
+ artifactIdchef/artifactId
+ packagingbundle/packaging
+ namejclouds Chef api/name
+ descriptionjclouds components to access Chef/description
+
+ properties
+test.chef.endpointhttp://localhost:4000/test.chef.endpoint
+test.chef.api-version /
+test.chef.build-version /
+test.chef.identitychef-webui/test.chef.identity
+test.chef.credential${user.home}/.chef/webui.pem/test.chef.credential
+jclouds.osgi.import
+ org.project.version=${project.version},
It turns out that this line is causing the karaf itest failures. It looks like
a regex search and replace accident.
Should be:
```
org.jclouds;version=${project.version},
```
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/536/files#r18411350
Re: [jclouds] Moved jclouds-chef to the main repo (#536)
+1 With the above osgi import fix and the fix for #537. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/536#issuecomment-57835484
[jira] [Commented] (JCLOUDS-172) Graduate GCE to core
[ https://issues.apache.org/jira/browse/JCLOUDS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14144940#comment-14144940 ] Chris Custine commented on JCLOUDS-172: --- This is going to take a few days to get these PRs all up to date and merged before we move to the main jclouds repo, but that is the current plan before we release 1.8.1. There are also some outstanding issues that were recently reported and I am going to try to get those resolved before the move. Graduate GCE to core -- Key: JCLOUDS-172 URL: https://issues.apache.org/jira/browse/JCLOUDS-172 Project: jclouds Issue Type: Task Components: jclouds-labs-google Affects Versions: 1.8.0 Reporter: Andrew Bayer Assignee: Chris Custine Priority: Critical We should really get GCE to a finished state and include it in 1.7.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jclouds-labs-google] initial commit to support GCE LB (#22)
I spoke to @andreaturli today and he is hoping to work on finalizing this next week so that we can merge this and #38 before graduating to jclouds/jclouds. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/22#issuecomment-56577803
[jira] [Commented] (JCLOUDS-172) Graduate GCE to core
[ https://issues.apache.org/jira/browse/JCLOUDS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14145316#comment-14145316 ] Chris Custine commented on JCLOUDS-172: --- [~gaul]: I had thought that 1.8.1 was the target based on recent discussions with various people, but I may have misunderstood. Personally, I am not opposed to graduating a @Beta provider to the main repo in a minor release just because Maven artifact changes, but if everyone wants to wait for 2.0 that is fine too. It is going to take another few days to finalize and merge the above mentioned PRs and recent issues so we have at least a week to discuss and decide. Graduate GCE to core -- Key: JCLOUDS-172 URL: https://issues.apache.org/jira/browse/JCLOUDS-172 Project: jclouds Issue Type: Task Components: jclouds-labs-google Affects Versions: 1.8.0 Reporter: Andrew Bayer Assignee: Chris Custine Priority: Critical We should really get GCE to a finished state and include it in 1.7.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-172) Graduate GCE to core
[ https://issues.apache.org/jira/browse/JCLOUDS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14143490#comment-14143490 ] Chris Custine commented on JCLOUDS-172: --- Hi [~erjohnso] It looks like there are some loose ends on those PRs but I will try to follow up on them. Graduate GCE to core -- Key: JCLOUDS-172 URL: https://issues.apache.org/jira/browse/JCLOUDS-172 Project: jclouds Issue Type: Task Components: jclouds-labs-google Affects Versions: 1.8.0 Reporter: Andrew Bayer Assignee: Chris Custine Priority: Critical We should really get GCE to a finished state and include it in 1.7.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jclouds-labs-google] JCLOUDS-703 missing imageSpaceGb from machineType (#49)
I can also confirm this. I tested using curl for get, list, and aggregatedList varieties and none of them returned imageSpaceGb. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/49#issuecomment-55471368
Re: [jclouds-labs-google] JCLOUDS-703 missing imageSpaceGb from machineType (#49)
I starred and commented on the ticket as well. I'm not sure if we should pre-emptively apply this PR until we get some comment from Google on the ticket. If we remove this property and it comes back as a bug in GCE that they fix, we will have to track the resolution manually as it won't be obvious if it shows back up again. The fix LGTM, but lets give them some time to address the ticket. If there is no resolution before the next jclouds release I will be +1 to go ahead and apply the fix anyway. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/49#issuecomment-55472034
Re: [jclouds-cli] Update karaf version to latest 2.3.6 (#18)
@@ -24,6 +24,7 @@ groupIdorg.apache.jclouds/groupId artifactIdjclouds-project/artifactId version2.0.0-SNAPSHOT/version +relativePath / @demobox Yeah, you have the gist of it now. There is a long running debate about this but I doubt it will ever be resolved: https://jira.codehaus.org/browse/MNG-5146 In the mean time, I just religiously put that in every pom referring to a remote parent because I can't stand false warnings and garbage in my build output. I will put this in the new PR when I get that all resolved. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-cli/pull/18/files#r16559674
Re: [jclouds-karaf] Using ServiceMix bundle for jsch-agentproxy-sshj (#53)
@@ -202,6 +202,7 @@ limitations under the License.
joda.version2.1/joda.version
jsch.bundle.version0.1.44_2/jsch.bundle.version
jsch.agentproxy.version0.0.7/jsch.agentproxy.version
+
jsch.agentproxy.bundle.version${jsch.agentproxy.version}_2/jsch.agentproxy.bundle.version
...and I stand corrected, it IS used elsewhere so disregard my statement :-)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-karaf/pull/53/files#r16561353
Re: [jclouds-karaf] Using ServiceMix bundle for jsch-agentproxy-sshj (#53)
:+1: and I'll repeat that if any servicemix bundle stuff comes up again let me know and I can get it in quickly. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-karaf/pull/53#issuecomment-52969565
Re: [jclouds-labs-openstack] Swift API Updates (#129)
* @return The {@link Account} object.
*/
@Named(account:get)
@HEAD
@ResponseParser(ParseAccountFromHeaders.class)
- @Path(/)
I'm assuming / is default with no @Path annotation? (I looked but couldn't
quickly confirm that).
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/129/files#r16502665
Re: [jclouds] Add top-level legacy directory (#489)
Just a thought... an alternative could be to remove them from the default build and add a -Plegacy profile build, leaving them where they are. If the concern from Jeremy is that moving say, openstack-swift and rackspace-cloudfiles* to the main jclouds project will cause confusion on which one to use, then I agree that we should move up the discussion of just deleting the old ones. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/489#issuecomment-52534069
Re: [jclouds] Fix Karaf bundle scoping in Cloud Load Balancers (#490)
+1 There is also a way to do this with macros that will use the maven project version as a basis for this range. I will put that in my generic PR for updating the karaf and cli projects, as it will automatically set these ranges along the lines of semver such as [2,3) if you maven project is 2.1, 2.3, etc. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/490#issuecomment-52555870
[jclouds] Move checkstyle copyright header into checkstyle.xml (#492)
You can merge this Pull Request by running: git pull https://github.com/ccustine/jclouds features/checkstyleheader Or you can view, comment on it, or merge it online at: https://github.com/jclouds/jclouds/pull/492 -- Commit Summary -- * Move checkstyle copyright header into checkstyle.xml -- File Changes -- M resources/checkstyle.xml (17) D resources/copyright_header.txt (16) M resources/pom.xml (1) -- Patch Links -- https://github.com/jclouds/jclouds/pull/492.patch https://github.com/jclouds/jclouds/pull/492.diff --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/492
Re: [jclouds] Move checkstyle copyright header into checkstyle.xml (#492)
@demobox Good question, I will test that out. @andrewgaul I missed the two references in project/pom.xml, I've removed them now. I will check Windows as that would be a blocker. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/492#issuecomment-52562562
Re: [jclouds] Move checkstyle copyright header into checkstyle.xml (#492)
I can confirm that this patch also works properly when building on windows. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/492#issuecomment-52577153
Re: [jclouds] Enforce ASF copyright header via Checkstyle (#472)
Backported to [1.8.x](https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=commit;h=d3234b7299f38785b9ddd4a71ef6799d678ee3de) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/472#issuecomment-52578914
Re: [jclouds] fix ASF copyright headers on SoftLayer (#476)
Backported to [1.8.x](https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=commit;h=59dcf2474fea950887fa061325c865610463d754) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/476#issuecomment-52579050
Re: [jclouds] Move checkstyle copyright header into checkstyle.xml (#492)
Pushed to Apache [master](https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=commit;h=192785dbaedc16eeec87ce7783fb8fbb136e7055) Backported to Apache [1.8.x](https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=commit;h=d3234b7299f38785b9ddd4a71ef6799d678ee3de) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/492#issuecomment-52579219
Re: [jclouds-cli] Update karaf version to latest 2.3.6 (#18)
I'll update jclouds-karaf to match and see how little we can get by with in 1.8.x. I think what was happening is that one of the 3rd party jclouds dependencies had a bundle version constraint requiring a newer osgi framework version. The Karaf version 2.2.7 was over 2 years old at this point, so I'm not surprised that the newer bundles didn't resolve. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-cli/pull/18#issuecomment-52387039
[jira] [Created] (JCLOUDS-675) Upgrade CLI to Karaf 3.0
Chris Custine created JCLOUDS-675: - Summary: Upgrade CLI to Karaf 3.0 Key: JCLOUDS-675 URL: https://issues.apache.org/jira/browse/JCLOUDS-675 Project: jclouds Issue Type: Improvement Components: jclouds-cli, jclouds-karaf Affects Versions: 1.8.0 Reporter: Chris Custine Assignee: Chris Custine Karaf 2.3.x is not going to be compatible with JRE 1.8 due to lack of support in 3rd party bundles such as ASM and Aries. jclouds 2.0 is probably a good release to target an upgrade to Karaf 3.0 which packages new versions of the required bundles with JRE 1.8 support. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [jclouds] Prefer isEmpty() for collections (#488)
Oh heck yeah, +1! --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/488#issuecomment-52340226
Re: [jclouds-labs-google] JCLOUDS-633: Support passing bearer token directly for OAuth2 (#34)
@demobox Actually it is :-( Is it ok to just fix these directly on Apache? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/34#issuecomment-52341042
Re: [jclouds-labs-google] JCLOUDS-633: Support passing bearer token directly for OAuth2 (#34)
Fixed, and thanks for the heads up. I am REALLY going to figure out how to get IDEA to make this more obvious before I check in... I promise :-) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/34#issuecomment-52342497
[jclouds-cli] Update karaf version to latest 2.3.6 (#18)
Hopefully fixing: https://issues.apache.org/jira/browse/JCLOUDS-673 https://issues.apache.org/jira/browse/JCLOUDS-674 You can merge this Pull Request by running: git pull https://github.com/ccustine/jclouds-cli features/karafupdate Or you can view, comment on it, or merge it online at: https://github.com/jclouds/jclouds-cli/pull/18 -- Commit Summary -- * Update karaf version to latest 2.3.6 -- File Changes -- M assembly/src/main/filtered-resources/etc/startup.properties (9) M project/pom.xml (25) M runner/src/main/java/org/jclouds/cli/runner/Main.java (2) -- Patch Links -- https://github.com/jclouds/jclouds-cli/pull/18.patch https://github.com/jclouds/jclouds-cli/pull/18.diff --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-cli/pull/18
Re: [jclouds-cli] Update karaf version to latest 2.3.6 (#18)
@andrewgaul This solves those issues for me on both master and 1.8.x builds. I think this fixes several other imminent issues with bit rot from outdated/missing osgi bundles. I might take a stab at updating master to Karaf 3.0.1 this weekend, but at least this brings the dependencies up to more recent levels. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-cli/pull/18#issuecomment-52376844
[jira] [Commented] (JCLOUDS-673) jclouds-cli interactive mode does not have any commands
[
https://issues.apache.org/jira/browse/JCLOUDS-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14099412#comment-14099412
]
Chris Custine commented on JCLOUDS-673:
---
Possibly solved here: https://github.com/jclouds/jclouds-cli/pull/18
I only tested hpcloud compute and object storage providers.
jclouds-cli interactive mode does not have any commands
---
Key: JCLOUDS-673
URL: https://issues.apache.org/jira/browse/JCLOUDS-673
Project: jclouds
Issue Type: Bug
Components: jclouds-cli
Affects Versions: 1.8.0
Reporter: Andrew Gaul
Attachments: jclouds-cli.txt
Upon launching, several errors of the form:
{noformat}
ERROR: Bundle org.apache.jclouds.karaf.core [51] Error starting
mvn:org.apache.jclouds.karaf/core/1.8.0 (org.osgi.framework.BundleException:
Unresolved constraint in bundle org.apache.jclouds.karaf.core [51]: Unable to
resolve 51.0: missing requirement [51.0] package;
((package=org.osgi.framework)(version=1.6.0)))
org.osgi.framework.BundleException: Unresolved constraint in bundle
org.apache.jclouds.karaf.core [51]: Unable to resolve 51.0: missing
requirement [51.0] package; ((package=org.osgi.framework)(version=1.6.0))
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3446)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1734)
at
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1163)
at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:745)
{noformat}
No jclouds commands found:
{noformat}
jclouds blobstore-container-list
Command not found: blobstore-container-list
{noformat}
Note that non-interactive mode works.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: [jclouds-labs-google] JCLOUDS-661: Add ability to create single port firewall rule from Securi... (#39)
I took the liberty of backporting this to [Apache 1.8.x](https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=2f92f1c) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/39#issuecomment-52242952
Re: [jclouds] Adding test for single port firewall rule (#477)
Backported to [Apache 1.8.x](https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=6fa3651) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/477#issuecomment-52243085
Re: [jclouds] Configures Checkstyle plugin to fail build on warnings (#464)
:+1: This will help reduce overhead on reviews, and shame guys like me into getting checkstyle review as part of my local workflow in my IDE :-) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/464#issuecomment-52099949
Re: [jclouds-labs-google] JCLOUDS-643: Fix Google and OAuth tests (#37)
@demobox I rebased and checked live tests again and I am using this to validate my Apache credentials, and merge workflow, etc :-) Should be incoming shortly. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/37#issuecomment-52100325
Re: [jclouds-labs-google] JCLOUDS-643: Fix Google and OAuth tests (#37)
Pushed to [Apache master](https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=a0d0c4c) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/37#issuecomment-52102050
Re: [jclouds-labs-google] JCLOUDS-643: Fix Google and OAuth tests (#37)
Backported to [Apache 1.8.x](https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=36614bb) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/37#issuecomment-52102996
[jira] [Resolved] (JCLOUDS-643) Fix Google and OAuth tests
[ https://issues.apache.org/jira/browse/JCLOUDS-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine resolved JCLOUDS-643. --- Resolution: Fixed Fix Version/s: 2.0.0 1.8.1 Assignee: Chris Custine Fix Google and OAuth tests -- Key: JCLOUDS-643 URL: https://issues.apache.org/jira/browse/JCLOUDS-643 Project: jclouds Issue Type: Bug Components: jclouds-labs-google Affects Versions: 1.7.3, 1.8.0 Reporter: Chris Custine Assignee: Chris Custine Priority: Minor Fix For: 1.8.1, 2.0.0 Google compute and OAuth tests are a bit out of date and live tests fail in several areas: GCEL images are deprecated in favor of Debian, live tests are inconsistent in how credentials are loaded, parallel tests all but guarantee maxing out the 5 network quota, and a few other issues. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [jclouds-labs-google] JCLOUDS-633: Support passing bearer token directly for OAuth2 (#34)
@@ -51,7 +53,10 @@ public GoogleComputeEngineServiceLiveTest() {
@Override
protected Properties setupProperties() {
Properties props = super.setupProperties();
- setCredentialFromPemFile(props, provider + .credential);
+ if
(!System.getProperties().containsKey(OAuthProperties.CREDENTIAL_TYPE)
+||
!System.getProperty(OAuthProperties.CREDENTIAL_TYPE).equalsIgnoreCase(CredentialType.BEARER_TOKEN_CREDENTIALS.toString()))
{
Yeah, much cleaner... I went ahead and used your suggestion.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-google/pull/34/files#r16207847
Re: [jclouds-labs-google] JCLOUDS-633: Support passing bearer token directly for OAuth2 (#34)
@@ -40,4 +40,10 @@ * Optional list of comma-separated scopes to use when no OAuthScopes annotation is present. */ public static final String SCOPES = jclouds.oauth.scopes; + + /** +* Optional list of comma-separated scopes to use when no OAuthScopes annotation is present. Indeed, fixed... --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/34/files#r16207910
Re: [jclouds-labs-google] JCLOUDS-633: Support passing bearer token directly for OAuth2 (#34)
I am currently live testing this manually by running the live tests once with id and pk, and then again with a valid token. The token retrieved after an initial oauth token request is not readily available via the api (therefore not available for a live test), so I am going to create a new issue to implement that (also related to https://issues.apache.org/jira/browse/JCLOUDS-518) and the tests for those features will automatically test this in a single live test run. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/34#issuecomment-52115472
Re: [jclouds-labs-google] JCLOUDS-633: Support passing bearer token directly for OAuth2 (#34)
Squashed commits, rebased on master, and ran live tests with both auth schemes. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/34#issuecomment-52117699
Re: [jclouds-labs-google] JCLOUDS-633: Support passing bearer token directly for OAuth2 (#34)
Closed #34. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-google/pull/34#event-152625315
[jira] [Resolved] (JCLOUDS-633) Support passing bearer token directly for OAuth2
[ https://issues.apache.org/jira/browse/JCLOUDS-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine resolved JCLOUDS-633. --- Resolution: Fixed Fix Version/s: 2.0.0 1.8.1 Assignee: Chris Custine Support passing bearer token directly for OAuth2 Key: JCLOUDS-633 URL: https://issues.apache.org/jira/browse/JCLOUDS-633 Project: jclouds Issue Type: Improvement Components: jclouds-labs-google Affects Versions: 1.7.3 Reporter: Chris Custine Assignee: Chris Custine Priority: Minor Fix For: 1.8.1, 2.0.0 Currently the oauth code requires a service account for credentials and jclouds manages fetching a token and caching it. This is not ideal when integrating jclouds into a UI for any kind of tooling which might already be authenticating with oauth and already has a token. In such cases it would be ideal to pass in the project ID or account email as well as the previously retrieved token and bypass the fetching and caching of a new token. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [jclouds] Adding test for single port firewall rule (#477)
+1 I merged jclouds/jclouds-labs-google#37 and tested this PR along with jclouds/jclouds-labs-google#39 and all tests pass now so everything looks good to me at this point. I'll let @demobox have final say on this one. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/477#issuecomment-52145239
Re: [jclouds] Adding test for single port firewall rule (#477)
Yeah this PR will allow all variations of live tests to run: https://github.com/jclouds/jclouds-labs-google/pull/37 as well as several other issues you will get later when running live tests. I am going merge that one to test my Apache commit workflow here shortly, and I will also check with this PR and update here later. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/477#issuecomment-51992718
Re: [jclouds] Prefer OpenStack Regions (#463)
I noticed the same things as @zack-shoylev but I have to admit, you would be exponentially increasing the workload as you would at multiple times be changing/adding code that you know is going to be removed in the last PR of the series. I think in this case I would have done it the same. +1 from me, and I have run live tests against all HP, Rackspace and local openstack environments I have at my disposal. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/463#issuecomment-51997917
[jira] [Assigned] (JCLOUDS-668) Create IpPermission for a single port
[ https://issues.apache.org/jira/browse/JCLOUDS-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine reassigned JCLOUDS-668: - Assignee: Chris Custine Create IpPermission for a single port - Key: JCLOUDS-668 URL: https://issues.apache.org/jira/browse/JCLOUDS-668 Project: jclouds Issue Type: Improvement Components: jclouds-labs-google Affects Versions: 1.7.3 Reporter: Sunil Shah Assignee: Chris Custine There doesn't appear to be an easy way to add a single port firewall rule on GCE. (e.g. UDP:1194) We get an IllegalStateException exception when trying to add a rule as follows: IpPermission.builder() .ipProtocol(protocol) .cidrBlock(Cidr.WORLD) .fromPort(number) .toPort(number) .build() securityGroupsExtension.addIpPermission(ipPermission, securityGroup) Exception: java.lang.IllegalStateException: start of range must be lower than end of range at com.google.common.base.Preconditions.checkState(Preconditions.java:150) ~[poseidon-0.2-SNAPSHOT-jar-with-dependencies.jar:na] at org.jclouds.googlecomputeengine.domain.Firewall$Rule$Builder.addPortRange(Firewall.java:354) ~[poseidon-0.2-SNAPSHOT-jar-with-dependencies.jar:na] at org.jclouds.googlecomputeengine.compute.extensions.GoogleComputeEngineSecurityGroupExtension.addIpPermission(GoogleComputeEngineSecurityGroupExtension.java:224) ~[poseidon-0.2-SNAPSHOT-jar-with-dependencies.jar:na] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (JCLOUDS-668) Create IpPermission for a single port
[ https://issues.apache.org/jira/browse/JCLOUDS-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine resolved JCLOUDS-668. --- Resolution: Duplicate Fix Version/s: 2.0.0 1.8.1 We had this reported a few days ago with along with a PR: https://github.com/jclouds/jclouds-labs-google/pull/39 Should be merged soon. Create IpPermission for a single port - Key: JCLOUDS-668 URL: https://issues.apache.org/jira/browse/JCLOUDS-668 Project: jclouds Issue Type: Improvement Components: jclouds-labs-google Affects Versions: 1.7.3 Reporter: Sunil Shah Assignee: Chris Custine Fix For: 1.8.1, 2.0.0 There doesn't appear to be an easy way to add a single port firewall rule on GCE. (e.g. UDP:1194) We get an IllegalStateException exception when trying to add a rule as follows: IpPermission.builder() .ipProtocol(protocol) .cidrBlock(Cidr.WORLD) .fromPort(number) .toPort(number) .build() securityGroupsExtension.addIpPermission(ipPermission, securityGroup) Exception: java.lang.IllegalStateException: start of range must be lower than end of range at com.google.common.base.Preconditions.checkState(Preconditions.java:150) ~[poseidon-0.2-SNAPSHOT-jar-with-dependencies.jar:na] at org.jclouds.googlecomputeengine.domain.Firewall$Rule$Builder.addPortRange(Firewall.java:354) ~[poseidon-0.2-SNAPSHOT-jar-with-dependencies.jar:na] at org.jclouds.googlecomputeengine.compute.extensions.GoogleComputeEngineSecurityGroupExtension.addIpPermission(GoogleComputeEngineSecurityGroupExtension.java:224) ~[poseidon-0.2-SNAPSHOT-jar-with-dependencies.jar:na] -- This message was sent by Atlassian JIRA (v6.2#6252)
