i find swift too slow as a persistence endpoint in any case; it doesn't
seem to be designed for the high-transaction rate we do. would losing
swift hurt anyone?
what are the other 2.0.0 changes/risks?
the reason i push for this is that i've several times hit problems with
brooklyn using jclouds 192 that we fixed in jclouds in the *spring*.
--a
On 16/11/2016 09:32, Aled Sage wrote:
Hi all,
I favour towards a 0.11.0 for jclouds 2.0.0 soon, with 0.10.0
depending on jclouds 1.9.2.
That allows users to have a stable release if they want to keep using
1.9.2 (e.g. if things break in 2.0.0, or they want to update more
leisurely), but other users can get 2.0.0 once we've had a little
longer to test with that.
For example, jclouds "swift" is deleted in 2.0.0, replaced with
"openstack-swift". Unfortunately SoftLayer's object store uses an
older version of swift that is not compatible with this, so I believe
does not work with openstack-swift [1]. Upgrading to 2.0.0 would
therefore break SoftLayer's object store as a persistence endpoint.
Aled
[1] https://issues.apache.org/jira/browse/BROOKLYN-359
On 16/11/2016 15:44, Alex Heneveld wrote:
There have been a lot of improvements to jclouds since their 1.9.2
release. Unless there are big issues with using 2.0.0 that would get
my vote.
Best
Alex
On 16/11/2016 07:26, Andrea Turli wrote:
+1
Svet,
FYI I'm working on #409 and #415 now that jclouds 2.0 is official
released.
Andrea
On 16 November 2016 at 12:33, Svetoslav Neykov <
svetoslav.ney...@cloudsoftcorp.com> wrote:
Is including jclouds 2.0 too big of a change to consider, what do
people
think?
If that's considered too risky then I suggest following with a
0.11.0 not
too long after, including jclouds 2.0.
There's already work to get it running with Brooklyn at
https://github.com/apache/brooklyn-server/pull/415 <
https://github.com/apache/brooklyn-server/pull/415> and
https://github.com/apache/brooklyn-server/pull/409 <
https://github.com/apache/brooklyn-server/pull/409>.
Svet.
On 16.11.2016 г., at 13:22, Aled Sage <aled.s...@gmail.com> wrote:
Hi all,
It's far past time that we did a Brooklyn 0.10.0 release! I
suggest we
aim for that soon.
To that end, I suggest the following steps:
* Deal with open PRs:
o People shout out about any PRs you think are very important to
be merged, before that release.
o Review open PRs
(for any that won't get merged into 0.10.0, clearly mark
them as
such and say why).
* Any pending/remaining work:
o Give people until Friday evening (uk time) to submit any other
very important PRs that are being working on.
o People shout out about any known issues that they see as
blockers for a release.
* Do some initial testing, using master (before Friday).
* Aim to produce a first release candidate on Friday evening (uk
time).
* Do the usual QA/fix cycle until the release is ready.
* Write release notes, etc.
Of the first steps, reviewing the PRs is a big piece of work! If you
have time to help, then please lend a hand by reviewing and/or
testing the
PRs, and commenting on them.
I don't think we should try to squeeze lots of additional PRs into
0.10.0 - there is already a huge amount in there compared to 0.9.0!
Richard, are our release process docs up-to-date at [1]?
Aled
[1] http://brooklyn.apache.org/developers/committers/release-
process/index.html
