Forwarding this to the dev@ list...
TL;DR: Fine by me if we're OK to release with a workaround and without
a fixed Guava version.
This bug is really hurting our users. We need to stop the bleeding.
Were constantly asking users to use a snapshot release but what we
really need to do is
Yeah, I think we're ok for the workaround with 1.7.1. Let's do that ASAP.
Who can spin the wheels on this one? I'm afraid I'm stuck at an event
all day tomorrow :-(
Also: are there any other urgent PRs for 1.7.x we'd like to include here?
ap
I'll cut the release tomorrow then and will include the DigitalOcean
provider.
I plan to start the release tomorrow at 9:00 AM (CET), which is in 12
hours or so and if I get in trouble I'll wait for you :) Does this
work?
Works for me too. Thanks, Ignasi! I guess that means that 1.7.x is
Many thanks for getting this out so quickly, Ignasi! Will try to test
earlier tomorrow as well...
ap
===
Apache ID: andrewp
---
[X] +1 Release.
[ ] -1 Don't release (see notes).
---
Checklist
My vote is based on running the verification on
Java version: 1.7.0_40, vendor: Oracle Corporation
I should add. Cf. JCLOUDS-427.
ap
[1] https://issues.apache.org/jira/browse/JCLOUDS-427
Do we have a canonical copy of this script?
I think the canonical version is still the one linked to from the
Verifying jclouds page [1], i.e. in abayer's home dir. We could
probably put it (and the Windows version, for what that's worth) in a
shared repo somewhere, if desirable?
Thanks
On a side note, the draft could do with a little update by the end of
the day, as we're about to release 1.7.1 if all goes well. But I'm
sure we could also include that in the next report if we need this
filed *now*.
ap
I'll start the release process in short.
Great! Many thanks, Ignasi!
ap
All tags/branches are now pushed and the release is in progress. As
soon as the released artifacts appear on the mirrors I'll send the
ANNOUNCE email.
Thanks all for your feedback!
Is the 1.7.x branch open again, or should we rather wait until Nexus
is finished..?
ap
Thanks for going through and closing/cleaning up so many of the
legacy-jclouds PRs, Andrew G!
ap
What do we feel still needs to be done before we can get the new site
design up and running..?
ap
Just an FYI that the Javadocs and Maven site for 1.7.1 are now available:
http://demobox.github.io/jclouds-maven-site/1.7.x/apidocs/ (quicklink)
http://demobox.github.io/jclouds-maven-site-1.7.1/1.7.1/jclouds/apidocs/
ap
Are they only used to get the name of the method whcih subsequently is fed
to the url of the http request???
jclouds uses these methods to automatically generate HTTP invocations.
The class that achieves most of this is the RestAnnotationProcessor. [1]
Another question is why dynamic
Congrats! Perhaps the cloud-storage-workshop [1] stuff can come in
handy in helping you put some material together. Let me know if you'd
like any review feedback or similar!
ap
[1] https://github.com/jclouds/jclouds-cloud-storage-workshop
The release notes for 1.7.1 are available too:
http://jclouds.apache.org/documentation/releasenotes/1.7.1/
Thanks, Ignasi!
ap
builds fail and the staging site is not populated. To fix this, I've
rebased all changes to the latest maater version and pushed a new
branch called rebranding-rebased. Please, continue the rebranding
work in that branch.
Thanks for taking care of that, Ignasi!
ap
branch called rebranding-rebased. Please, continue the rebranding
work in that branch.
I notice the original rebranding branch is still around. Do we want
to keep that as a record of work so far until the redesign is merged,
or is it no longer required..?
ap
I see that the BaseBlobStore and BaseProviderMetadata classes can have some
implemented methods. But then what is the use of the interface on top of
that?
The Base* classes are intended mainly as convenience classes for
*implementers* of providers. The implemented methods you've found
cloud services such as: payment service, image manipulation service etc.
Such services are gaining popularity in PaaS marketplaces ( Heroku,
engineyard, Amazon) and thought it would be nice to create a cloud API
(similar to jcouds) for each of those services.
If you're looking at the potential
I'm trying to see if it's possible to modify the create() method so
that I can inject the list of private IP addresses instead of taking
random values assigned by OpenStack.
I think JCLOUDS-416 [1] might help you, if I am understanding your
question correctly..?
ap
[1]
Does this make sense? Am I missing something obvious, or is there a
problem here?
Looks like your troubleshooting is pretty spot on ;-) And I'd say (as
an outsider - I didn't implement the code so don't know the exact
intention) it looks like a bug to me. groupFromMapOrName definitely
In the case of non-jclouds created nodes, you can get the valid firewall
rules from a combination of the network and the tags on the
instance/firewall.
Sounds like we might need a pull request to update that portion of the
code? You might also want to look at:
in https://issues.apache.org/jira/browse/JCLOUDS-442 my intent was to avoid
the creation of too many firewalls as the current implementation is doing.
Looking briefly at the code in the PR, I don't think so. As far as I
can see, the code still expects to be able to get a non-null group and
I saw that there is a PR for supporting Orion-based backends in
jClouds at https://github.com/jclouds/jclouds-labs/pull/45. May I ask
about news regarding that PR? O:)
Thanks for the ping, Oliver. As far as I know, at present all that
we're waiting for are sufficient review cycles to go
I am looking for a piece of documentation or example that helps to
implement a new API or provider with jClouds. As an example motivation,
let's say that I want to implement jClouds API in a local or mock
environment. How should I start with that?
If you want to start with a simple local mock,
1.7.1 released on 11 February so I propose that we start the 1.7.2
release process the week of 31 March to follow our six week cadence.
Does anyone want to volunteer for this release?
Unfortunately, I'm on the road a lot that week, but am happy to pick
this on up if we can handle a little bit
So essentially it's coming due early April for the board meeting on
the 16th. Generally it needs to be in SVN a week before the Board
meeting, which is the 9th, and at the end of ApacheCon.
Thanks for clarifying, David. I've posted a first draft here [1].
Obviously, some issues (e.g. the
I was able to fix all the test failures. Attached the patch to
JCLOUDS-509. Please review.
Do you have a GitHub account, Lahiru? I can't find one that looks
obviously like you ;-)
ap
Any thoughts/comments on the April board report draft [1]? If not, I
propose we file soon, so we don't miss the deadline this time?
ap
[1] https://wiki.apache.org/jclouds/AprilBoardReportProposal
1.7.1 released on 11 February so I propose that we start the 1.7.2
release process the week of 31 March to follow our six week cadence.
Does anyone want to volunteer for this release? Currently addressed
issues:
Andrew, WDYT? Can we do a review effort tomorrow (I'll do :D) and if
comments cane be addressed quickly (and properly), include it in the
release?
I'll try. It looks like we have a few days before kicking off 1.7.2
after Jeremy's request, too.
ap
We have another 1.7.2 challenge: JCLOUDS-511 (support for ssh agent
authentication) seems to have broken Karaf, since it added new
dependencies which are not available as OSGi bundles.
A quick fix would be to revert the backport of JCLOUDS-511 to 1.7.x,
but it would obviously be nice if we
Personally, I'd rather remove individual references from the reports, as
we've all been busy doing stuff.
I've updated the report to remove the mentions [1], and will file by
the end of the week if there are no additional changes anyone would
like to make.
ap
[1]
I'm stuck travelling during the day today, so won't be able to start
the release until the evening. Unless anyone urgently needs more time,
I'd be planning to start cutting the release when I get back online
this evening EDT.
ap
Can you wait until 11:30 am EDT to start the release on Friday?
Sure! I would then suggest waiting until Monday? That will barely
change the vote deadline, since we don't count weekends, but gives us
three extra days to clean things up. Does that sound reasonable?
I was going to ask what
I tried to check out
https://svn.apache.org/repos/private/foundation/board/ as per the
board reporting guide [1] but am getting an access denied error. Is
perhaps the PMC chair the only person with access rights to this?
I haven't checking if I can send the requested email to
Yes, that will only be available to folks with member or officer karma.
If necessary, I can check it in.
That would be appreciated - the text is on the Wiki [1]. Will you also
send the email to board@, or should I be able to do that myself?
Thanks!
ap
[1]
I'll be kicking off the 1.7.2 release soon. Please consider the 1.7.x
branch frozen until further notice.
I forgot to add: please ensure any JIRA issues you've been working on
are up-to-date. I won't be sending out any vote emails before
lunchtime PDT, so anyone on the West Coast will
both times my mail has been rejected by the spamfilter. heh.
Tee hee. Thanks!
ap
The Apache jclouds PPMC is proud to announce that Jeremy Daggett has become a
committer on the project! Welcome aboard, Jeremy!
ap
I'll be kicking off the 1.7.2 release soon. Please consider the 1.7.x
branch frozen until further notice.
Thanks!
ap
I had a chat with Tal Yacobi from hp recently - they're doing some
research on how PaaS is being used today, what the development
experience/expectations are etc.
If anybody is interested in taking the survey he came up with for a
chance at a $300 Amazon gift card, here's the link:
s/PPMC/PMC/g. =)
Copy-paste strikes again! Thanks for catching that ;-)
ap
Are you still in the process of cutting an RC for jclouds 1.7.2? Or
has it completed already?
I'm just about the send out the [VOTE] email for the first RC. If
anything turns out to be really badly broken, please comment in the
[DISCUSS] thread, and we can see how best to address it.
This thread is for discussion of the first release candidate for
Apache jclouds-1.7.2. Please use this thread for discussion of issues
uncovered in the RC, questions you may have about the RC, etc.
Thanks!
ap
Hello,
This is the first release candidate for Apache jclouds 1.7.2.
Please use the separate [DISCUSS] thread for anything but votes.
It fixes the following issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326178styleName=HtmlprojectId=12314430
*** Please download,
In any case, please share the results of your tests in the DISCUSS thread,
as we may link to it from the release notes.
Yes, indeed. Sorry - I certainly didn't mean to say only share you're
results if they're bad...*all* test results are welcome and useful!
ap
I don't see a DISCUSS thread.
Should be there now [1]. Do you think you could attach the actual test
results (i.e. logs) there (see e.g. [2])?
3) Not sure how I could run tests of our product using mvn and the
newly built jars.
The easiest way is to add the two staging repositories
Are there any means available to understand jclouds code in order to
understand and contribute to it. Any resources such as architecture
A couple of links and discussion threads that may be useful, if you
haven't seen them already:
-1
*sigh*. But glad we spotted this.
I'll go and cancel the vote, then...
ap
We’ve discovered a blocker in the fix for JCLOUD-317 [1].
Due to a blocker that Everett discovered, this vote is being
cancelled. We will respin once the issue has been fixed.
Thanks to everyone for testing!
ap
Andrew, can you please babysit this PR (close and reopen as
necessary to trigger builds)?
I need to catch my flight back to Austin. I’ll be back online late afternoon.
Will do. Change looks fine, though.
Thanks, and have a safe flight!
ap
Thanks for this, Ignasi. Indeed, I think we can safely say that these
results should carry over to RC2, with the exception of
rackspace-cloudservers-us. Curious to know what is causing the
failures there...
ap
Everett's patch [1] looks fine - about to merge. I'll respin RC2 this
evening, so if there are any other blockers that need to be addressed,
please let me know before then!
ap
[1] https://github.com/jclouds/jclouds/pull/342
FYI: RC2 preparation in progress. I've also updated the release guide
with a section on cancelling the vote [1]. Specifically, I've added
instructions to git revert the release commit and push them, rather
than just reverting them locally.
I know we haven't had any consistent policy on
Hello,
This is the second release candidate for Apache jclouds 1.7.2.
Please use the separate [DISCUSS] thread for anything but votes.
It fixes the following issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326178styleName=HtmlprojectId=12314430
*** Please download,
This thread is for discussion of the second release candidate for
Apache jclouds 1.7.2. Please use this thread for discussion of issues
uncovered in the RC, questions you may have about the RC, etc.
Thanks!
ap
Should a new DISCUSS thread for rc2 be started? :)
Yes, certainly. I thought I had sent it (my mail client told me so),
but it indeed never seems to have left my Draft folder.
Thanks for the reminder, Ignasi!
ap
Not sure these failures should prevent us to release 1.7.2-rc2 as a
big refactoring that fixes all of the problems
Yes, since these are known issues that will be addressed soon, but are
not quite ready yet to be fixed *immediately*, I hope we're all OK to
proceed with 1.7.2.
Is that a
I'd like to test the 1.7.2-rc2 bits similar to what I did for rc1.
I'll do this after taking care of some other higher priority items at
work today. I should have the results latest by tomorrow evening PDT.
Thanks, Shri. No rush - the vote is open until at least next Tuesday ;-)
ap
===
Apache ID: andrewp
---
[X] +1 Release.
[ ] -1 Don't release (see notes).
---
Checklist
Quoting Jeremy Daggett jeremy.dagg...@gmail.com:
Picking back up on this topic...
I am actually leaning towards option 1 now.
One thing that is really handy with varargs is that rather than providing
multiple methods, we can have a single method in an interface. It could
really simplify the
Thanks for the heads-up, sebb! I generated the following file using
the form on the DOAP page:
http://pastie.org/private/l6mzbfhgyzohwgnik4xq
I think most of the links should be OK. The piece of information I'm
least sure about is the maintainer - I don't know if a group is
acceptable
I've created a PR to add the DOAP file to jclouds-site [1]. Probably a
better place for review and edits.
ap
[1] https://github.com/jclouds/jclouds-site/pull/75
Some stats about jclouds/jclouds PRs. Not sure they all make sense to
me, but some are quite interesting...
http://ghtorrent.org/pullreq-perf/jclouds-jclouds/
ap
Thoughts?
Definitely think this is a good idea. Not sure whether this is
something to combine with the release process, or just something we
should do on a scheduled basis anyway - once a month, say?
Something to add to Ignasi's really nice PR dashboard [1, 2]?
ap
[1]
Either is fine, but I assume the canonical source is Git, so I have
added that:
Yes, it is - the site itself is indeed a derived artifact.
Thanks!
ap
We can close this vote tomorrow morning if we get another +1 (no
problem waiting longer, of course). So if anyone on the PMC has time
to verify the RC today, that would be much appreciated!
ap
Thanks for the nudge AP. What's the Maven staging repo?
It’s missing from [1]
Ah...doh! Sorry about that. I'll also update the vote thread in a
second. Here it is:
https://repository.apache.org/content/repositories/orgapachejclouds-1009
ap
Maven staging repo:
Due to some sloppy copy-pasting, the Maven staging repo was not
mentioned in the original [VOTE] email. Here it is:
https://repository.apache.org/content/repositories/orgapachejclouds-1009
Since this is hopefully regarded as a convenience piece of
information and
I encountered several failures when using JDK 8
Ah, interesting. These are evidently things we are not catching with
the Java 8 DEV@cloud build, which isn't complaining at the moment...
Do you have the logs of those test failures, by the way?
ap
Actually, there are three branches that I think should be good to be removed:
* effective-jclouds
* rebranding
* rebranding-rebased
Unless anyone would like to keep one or more of these, I'd plan to
remove them at the end of next week (27th April).
Regards
ap
The only thing that branch has is the old site docs in the old-site
folder.
We've not needed it and it is already in the git/svn history, so I'd remove
the branches.
Done. Thanks for explaining, Ignasi!
ap
The vote is now closed, and with 4 binding +1s, we're ready to release.
+1:
* Andrew Phillips (binding)
* Ignasi Barrera (binding)
* Andrea Turli
* Everett Toews (binding)
* Andrew Gaul (binding)
0: none
-1: none
Thanks to everyone for testing this RC!
ap
The 1.7.x branches are open for use again. JIRA version 1.7.2 has been
marked as Released, and all issues that had that as a fix version,
but were still open, have been moved to 1.7.3 [1].
The Nexus staging repository has been released, and 1.7.2 is available
[2]. Still waiting for Maven
The Apache jclouds team is pleased to announce the release of jclouds 1.7.2.
This is the 4th Apache release of jclouds. Apache jclouds is an open
source multi-cloud toolkit for the Java platform that gives you the
freedom to create applications that are portable across clouds while
giving
*) When I try to run some live tests against a real Swift instance as
follows, it always fails.
See JCLOUDS-538 [1]. You will probably need to try to run the code
from the pull request, as well as add the properties
test.swift.endpoint, test.swift.identity and
test.swift.credential.
I
To get started with jclouds the best approach is to have a look at the
examples repo [1] and copy or use some of its projects, such as the
compute-basics, as a reference.
You may also want to look at:
https://wiki.apache.org/jclouds/Create%20a%20New%20API%20or%20Provider
That's a
I've added a Wiki page to document the current Maven site (and thus
Javadoc) generation process [1]. There's certainly room for
improvement, but from a couple of experiments it would seem that
a) moving away from Git repos as the target
b) trimming down what's actually generated
will be key
How do others feel about using the Guava MediaType [1] class for
MIME types instead of the (less robust) JAX-RS MediaType [2]
throughout the codebase going forward? We have discussed leveraging
more of the Guava libraries, and I figured I would throw it out
there. :)
See
Congrats to all of the students and thanks to all of the mentors!
Thanks to all the students and, of course, Andrew Gaul. Good luck all!
ap
Quoting Jeremy Daggett jeremy.dagg...@rackspace.com:
I am in the process of adding a few new pages to the wiki, and would
appreciate some feedback before pulling the trigger. Here is the
new layout I propose for the front page of our wiki:
* Architecture - new top level bullet
*
But still one issue. I have creates same Maven project but this time i have
replaces POM.xml and other code by simple example which i have downloaded
from Github.
Could you put the POM in a Gist or Pastie [1, 2] for us?
Thanks!
ap
[1] https://gist.github.com
[2] https://pastie.org
I am convinced that the Release It!² section could go under the
Committers Guide² since releases are only done by committers. WDYT?
Sounds reasonable. The new Publishing the API docs entry I put
together probably falls in the same category...
Thanks!
ap
Has someone tried to play with the -T maven parameter when
building jclouds?
Do you know which kind of instances do we have in Dev@cloud, and if we
could set that parameter?
I recall having tried it out a while back, only to discover that some
of the plugins we use were not compatible with
What data would we need on the DEV@cloud builds to start experimenting
here? Or should we simply add -T 2C or so to the PR builds and see
what happens?
ap
Added -T 2C to jclouds-pull-requests but *not* to
jclouds-java-7-pull-requests, so we should be able to see what (if
any) the difference is.
ap
Can anyone explain the background/history of this annotation? Other
than marking a parameter or return value to indicate that something
can be null, is there any code that does something special with it
at compile time?
Not as far as I am aware. It's intended as a user and developer
I did, and the new password seems to work with id.apache.org... just
not for git.
A push to jclouds-site.git just now worked for me. Weird.
ap
Added -T 2C to jclouds-pull-requests but *not* to
jclouds-java-7-pull-requests, so we should be able to see what (if
any) the difference is.
I'm afraid I've had to revert this change. This has been reliably
causing the jclouds-pull-request job [1] to fail with weird
compilation errors in dynect
I'm ok reverting the change, although it would be good to see if we
can determine why those weird compilation error occur, as in theory,
they shouldn't appear. Perhaps could be good to have a new build to
play with this?
Sure! See:
I've also seen this warning when running concurrent builds with Maven
3.0.4, so perhaps we should check if those plugins can be updated,
+1. Looks like a good question for the RAT plugin mailing lists..? [1]
Note that they seem to have already annotated rat:help as being
thread-safe [2],
Thanks to Everett [1], we now have a proper Javadoc link from
jclouds.apache.org [2], but are still looking at the easiest place to
host this documentation.
A GitHub repo (via GitHub Pages) is an option we've used previously,
but I recall that running into repo size/Pages generation issues
We could update the parent pom to version 14, which already updates the rat
plugin from 0.8 to 0.10 and see if the warning still appears.
Seems like an obvious PR candidate to me ;-)
ap
I also received some old notifications.
I'm not aware of any changes made to the repo itself that would be
causing this...does it affect other repos too, or just labs-aws?
ap
PS: I don't seem to have received any old notifications, by the way.
I'm not familiar with the APIs of other storage offerings like Google Drive
or Dropbox, but I'm not sure if they should fall in the same category. My
little knowledge suggests thay they don't have the same purpose. Object
storage and document storage (which is the topic of your thesis) sound
like
This makes me think that it may be better to have the project ID as a
context-wide parameter, and any time the compute service calls a
project-aware operation, it fills in the project ID. Security groups
are an example of something else that lives in project namespaces. Is
this a good route?
Just noticed this in a PR for vSphere support [1]:
+!--
+ Copyright 2014 Cisco Systems, Inc
+
+ Licensed under the Apache License, Version 2.0 (the License);
Can we accept such a copyright claim if the remainder of the Apache 2
license is included?
ap
[1]
As far as I understand the copyright policy [1], there shouldn't be a
copyright notice in the header. The way I understand it, pull requests
are contributions submitted directly to the ASF, so they don't fall
into the third-party work category, but I'm not a legal expert; it
would be great if
801 - 900 of 1315 matches
Mail list logo
