You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Ignasi Barrera <na...@apache.org> on 2015/06/28 00:04:42 UTC
DigitalOcean v2 to 1.9.x
Hi!
We're about to open PRs to merge the DigitalOcean v2 provider. Since
the v1 version will no longer be available starting on November [1]
(and is the only one we support now), I think we should include the v2
provider in 1.9.1. This will give users enough time to migrate and
test the new API (there are no breaking changes in it) before it is
shut down.
Before doing that, we have to agree how to proceed with its OAuth
dependency. DigitalOcean v2 depends on the OAuth API, which was
promoted to the main repo but only in 2.0.0, to avoid a groupId
change; in 1.9.x the oauth home is in the jclouds-labs-google repo.
This gives us the following options:
* Merge the digitalocean2 provider in jclouds-labs, and change the
"build order". jclouds-labs-google will have to be built before
jclouds-labs.
* Move the oauth api to jclouds-labs, and then merge digitalocean2
there. This implies that jclouds-labs-google will need to be built
after jclouds-labs, but that's what we are already doing implicitly.
The main issue here is that we are introducing a dependency between
labs repos we don't have now, but I think that having the DO v2
provider in 1.9.1 is worth it.
WDYT?
if there is an agreement to proceed, I'd vote for option 2 (move oauth
then merge the provider).
Take into account that there are no references to 'google' in ithe
OAuth api; it is just hosted in the labs-google repo. This means most
users won't be affected, as the Maven coordinates won't change.
I.
[1] https://developers.digitalocean.com/documentation/changelog/api-v1/sunsetting-api-v1/
Re: DigitalOcean v2 to 1.9.x
Posted by Andrea Turli <an...@gmail.com>.
Personally I've always consider jclouds-labs as a common repo for the labs
repos, so in my mind this implicit dependency has always been there.
Moreover, the recent changes to OAuth made this provider certainly useful
to many other providers, not only Google's, so I think it should go to
jclouds-labs.
My two cents,
Andrea
On Sun, Jun 28, 2015 at 9:00 AM Ignasi Barrera <na...@apache.org> wrote:
> If we move oauth to the jclouds-labs then there is no practical build order
> change, as we (our relesse scripts, our Jenkins build chain) always build
> jclouds-labs first.
>
> I'd like 2.0.0 to be feature driven instead of having a fixed dste for it:
> we need docker, azure and google properly promoted in it, and also
> DigitalOcean (it's been stable for ages in the v1 and having it incubating
> in 1.9.1 would allow us to promote it with confidence) and ideally
> CloudSigma2 and ProfitBricks.
>
> Also support for Guice 4 has been requested and I think 2.0.0 should be
> compatible.
>
> I really think we can't fix a date for 2.0.0 if we want to be able to ship
> all that, and other important stuff, in it.
> El 28/6/2015 5:18, "Andrew Gaul" <ga...@apache.org> escribió:
>
> > Theoretically I dislike changing the build order although practically
> > this has no impact. Will defer to whoever does the backport. What if
> > we accelerate the 2.0.0 release to avoid doing major surgery on the
> > release branch? We average a major release about every 7 months:
> >
> > 1.6.0/ 27-Apr-2013
> > 1.7.0/ 23-Dec-2013
> > 1.8.0/ 05-Aug-2014
> > 1.9.0/ 29-Mar-2015
> >
> > But instead we could plan 2.0.0 for August or September, 5 or 6 months.
> > This would give DO users a few months lead time.
> >
> > On Sun, Jun 28, 2015 at 12:04:42AM +0200, Ignasi Barrera wrote:
> > > Hi!
> > >
> > > We're about to open PRs to merge the DigitalOcean v2 provider. Since
> > > the v1 version will no longer be available starting on November [1]
> > > (and is the only one we support now), I think we should include the v2
> > > provider in 1.9.1. This will give users enough time to migrate and
> > > test the new API (there are no breaking changes in it) before it is
> > > shut down.
> > >
> > > Before doing that, we have to agree how to proceed with its OAuth
> > > dependency. DigitalOcean v2 depends on the OAuth API, which was
> > > promoted to the main repo but only in 2.0.0, to avoid a groupId
> > > change; in 1.9.x the oauth home is in the jclouds-labs-google repo.
> > > This gives us the following options:
> > >
> > > * Merge the digitalocean2 provider in jclouds-labs, and change the
> > > "build order". jclouds-labs-google will have to be built before
> > > jclouds-labs.
> > > * Move the oauth api to jclouds-labs, and then merge digitalocean2
> > > there. This implies that jclouds-labs-google will need to be built
> > > after jclouds-labs, but that's what we are already doing implicitly.
> > >
> > > The main issue here is that we are introducing a dependency between
> > > labs repos we don't have now, but I think that having the DO v2
> > > provider in 1.9.1 is worth it.
> > >
> > > WDYT?
> > >
> > > if there is an agreement to proceed, I'd vote for option 2 (move oauth
> > > then merge the provider).
> > >
> > > Take into account that there are no references to 'google' in ithe
> > > OAuth api; it is just hosted in the labs-google repo. This means most
> > > users won't be affected, as the Maven coordinates won't change.
> > >
> > >
> > > I.
> > >
> > >
> > >
> > >
> > > [1]
> >
> https://developers.digitalocean.com/documentation/changelog/api-v1/sunsetting-api-v1/
> >
> > --
> > Andrew Gaul
> > http://gaul.org/
> >
>
Re: DigitalOcean v2 to 1.9.x
Posted by Ignasi Barrera <na...@apache.org>.
If we move oauth to the jclouds-labs then there is no practical build order
change, as we (our relesse scripts, our Jenkins build chain) always build
jclouds-labs first.
I'd like 2.0.0 to be feature driven instead of having a fixed dste for it:
we need docker, azure and google properly promoted in it, and also
DigitalOcean (it's been stable for ages in the v1 and having it incubating
in 1.9.1 would allow us to promote it with confidence) and ideally
CloudSigma2 and ProfitBricks.
Also support for Guice 4 has been requested and I think 2.0.0 should be
compatible.
I really think we can't fix a date for 2.0.0 if we want to be able to ship
all that, and other important stuff, in it.
El 28/6/2015 5:18, "Andrew Gaul" <ga...@apache.org> escribió:
> Theoretically I dislike changing the build order although practically
> this has no impact. Will defer to whoever does the backport. What if
> we accelerate the 2.0.0 release to avoid doing major surgery on the
> release branch? We average a major release about every 7 months:
>
> 1.6.0/ 27-Apr-2013
> 1.7.0/ 23-Dec-2013
> 1.8.0/ 05-Aug-2014
> 1.9.0/ 29-Mar-2015
>
> But instead we could plan 2.0.0 for August or September, 5 or 6 months.
> This would give DO users a few months lead time.
>
> On Sun, Jun 28, 2015 at 12:04:42AM +0200, Ignasi Barrera wrote:
> > Hi!
> >
> > We're about to open PRs to merge the DigitalOcean v2 provider. Since
> > the v1 version will no longer be available starting on November [1]
> > (and is the only one we support now), I think we should include the v2
> > provider in 1.9.1. This will give users enough time to migrate and
> > test the new API (there are no breaking changes in it) before it is
> > shut down.
> >
> > Before doing that, we have to agree how to proceed with its OAuth
> > dependency. DigitalOcean v2 depends on the OAuth API, which was
> > promoted to the main repo but only in 2.0.0, to avoid a groupId
> > change; in 1.9.x the oauth home is in the jclouds-labs-google repo.
> > This gives us the following options:
> >
> > * Merge the digitalocean2 provider in jclouds-labs, and change the
> > "build order". jclouds-labs-google will have to be built before
> > jclouds-labs.
> > * Move the oauth api to jclouds-labs, and then merge digitalocean2
> > there. This implies that jclouds-labs-google will need to be built
> > after jclouds-labs, but that's what we are already doing implicitly.
> >
> > The main issue here is that we are introducing a dependency between
> > labs repos we don't have now, but I think that having the DO v2
> > provider in 1.9.1 is worth it.
> >
> > WDYT?
> >
> > if there is an agreement to proceed, I'd vote for option 2 (move oauth
> > then merge the provider).
> >
> > Take into account that there are no references to 'google' in ithe
> > OAuth api; it is just hosted in the labs-google repo. This means most
> > users won't be affected, as the Maven coordinates won't change.
> >
> >
> > I.
> >
> >
> >
> >
> > [1]
> https://developers.digitalocean.com/documentation/changelog/api-v1/sunsetting-api-v1/
>
> --
> Andrew Gaul
> http://gaul.org/
>
Re: DigitalOcean v2 to 1.9.x
Posted by Andrew Gaul <ga...@apache.org>.
Theoretically I dislike changing the build order although practically
this has no impact. Will defer to whoever does the backport. What if
we accelerate the 2.0.0 release to avoid doing major surgery on the
release branch? We average a major release about every 7 months:
1.6.0/ 27-Apr-2013
1.7.0/ 23-Dec-2013
1.8.0/ 05-Aug-2014
1.9.0/ 29-Mar-2015
But instead we could plan 2.0.0 for August or September, 5 or 6 months.
This would give DO users a few months lead time.
On Sun, Jun 28, 2015 at 12:04:42AM +0200, Ignasi Barrera wrote:
> Hi!
>
> We're about to open PRs to merge the DigitalOcean v2 provider. Since
> the v1 version will no longer be available starting on November [1]
> (and is the only one we support now), I think we should include the v2
> provider in 1.9.1. This will give users enough time to migrate and
> test the new API (there are no breaking changes in it) before it is
> shut down.
>
> Before doing that, we have to agree how to proceed with its OAuth
> dependency. DigitalOcean v2 depends on the OAuth API, which was
> promoted to the main repo but only in 2.0.0, to avoid a groupId
> change; in 1.9.x the oauth home is in the jclouds-labs-google repo.
> This gives us the following options:
>
> * Merge the digitalocean2 provider in jclouds-labs, and change the
> "build order". jclouds-labs-google will have to be built before
> jclouds-labs.
> * Move the oauth api to jclouds-labs, and then merge digitalocean2
> there. This implies that jclouds-labs-google will need to be built
> after jclouds-labs, but that's what we are already doing implicitly.
>
> The main issue here is that we are introducing a dependency between
> labs repos we don't have now, but I think that having the DO v2
> provider in 1.9.1 is worth it.
>
> WDYT?
>
> if there is an agreement to proceed, I'd vote for option 2 (move oauth
> then merge the provider).
>
> Take into account that there are no references to 'google' in ithe
> OAuth api; it is just hosted in the labs-google repo. This means most
> users won't be affected, as the Maven coordinates won't change.
>
>
> I.
>
>
>
>
> [1] https://developers.digitalocean.com/documentation/changelog/api-v1/sunsetting-api-v1/
--
Andrew Gaul
http://gaul.org/
Re: DigitalOcean v2 to 1.9.x
Posted by Ignasi Barrera <na...@apache.org>.
Thx for the feedback guys.
I've just pushed oauth and digitalocean2 to jclouds-labs and removed
the oauth folder from jclouds-labs-google in 1.9.x.
Before doing that I've checked how our Jenkins builds are configured,
and jclouds-labs-google is already started as a downstream job of the
jclouds-labs build, so there is nothing to change there. This also
means that the impact of the oauth api move will be very very minimal
(if any) as our release scripts and builds already assume that order,
and end-users mostly use the dependencies from Maven Central.
In any case, this shouldn't condition the discussion about 2.0.0, and
given the comment in this thread I think it would be good that we
start planning it in the ML.
I.
On 1 July 2015 at 01:16, Chris Custine <ch...@gmail.com> wrote:
> I'm +1 for moving consolidating oauth to jclouds-labs and releasing it from
> there in 1.9.1.
>
> --
> Chris Custine
>
>
>> Ignasi Barrera <ma...@apache.org>
>> June 27, 2015 at 4:04 PM
>>
>> Hi!
>>
>> We're about to open PRs to merge the DigitalOcean v2 provider. Since
>> the v1 version will no longer be available starting on November [1]
>> (and is the only one we support now), I think we should include the v2
>> provider in 1.9.1. This will give users enough time to migrate and
>> test the new API (there are no breaking changes in it) before it is
>> shut down.
>>
>> Before doing that, we have to agree how to proceed with its OAuth
>> dependency. DigitalOcean v2 depends on the OAuth API, which was
>> promoted to the main repo but only in 2.0.0, to avoid a groupId
>> change; in 1.9.x the oauth home is in the jclouds-labs-google repo.
>> This gives us the following options:
>>
>> * Merge the digitalocean2 provider in jclouds-labs, and change the
>> "build order". jclouds-labs-google will have to be built before
>> jclouds-labs.
>> * Move the oauth api to jclouds-labs, and then merge digitalocean2
>> there. This implies that jclouds-labs-google will need to be built
>> after jclouds-labs, but that's what we are already doing implicitly.
>>
>> The main issue here is that we are introducing a dependency between
>> labs repos we don't have now, but I think that having the DO v2
>> provider in 1.9.1 is worth it.
>>
>> WDYT?
>>
>> if there is an agreement to proceed, I'd vote for option 2 (move oauth
>> then merge the provider).
>>
>> Take into account that there are no references to 'google' in ithe
>> OAuth api; it is just hosted in the labs-google repo. This means most
>> users won't be affected, as the Maven coordinates won't change.
>>
>>
>> I.
>>
>>
>>
>>
>> [1]
>> https://developers.digitalocean.com/documentation/changelog/api-v1/sunsetting-api-v1/
>
>
Re: DigitalOcean v2 to 1.9.x
Posted by Chris Custine <ch...@gmail.com>.
I'm +1 for moving consolidating oauth to jclouds-labs and releasing it
from there in 1.9.1.
--
Chris Custine
> Ignasi Barrera <ma...@apache.org>
> June 27, 2015 at 4:04 PM
> Hi!
>
> We're about to open PRs to merge the DigitalOcean v2 provider. Since
> the v1 version will no longer be available starting on November [1]
> (and is the only one we support now), I think we should include the v2
> provider in 1.9.1. This will give users enough time to migrate and
> test the new API (there are no breaking changes in it) before it is
> shut down.
>
> Before doing that, we have to agree how to proceed with its OAuth
> dependency. DigitalOcean v2 depends on the OAuth API, which was
> promoted to the main repo but only in 2.0.0, to avoid a groupId
> change; in 1.9.x the oauth home is in the jclouds-labs-google repo.
> This gives us the following options:
>
> * Merge the digitalocean2 provider in jclouds-labs, and change the
> "build order". jclouds-labs-google will have to be built before
> jclouds-labs.
> * Move the oauth api to jclouds-labs, and then merge digitalocean2
> there. This implies that jclouds-labs-google will need to be built
> after jclouds-labs, but that's what we are already doing implicitly.
>
> The main issue here is that we are introducing a dependency between
> labs repos we don't have now, but I think that having the DO v2
> provider in 1.9.1 is worth it.
>
> WDYT?
>
> if there is an agreement to proceed, I'd vote for option 2 (move oauth
> then merge the provider).
>
> Take into account that there are no references to 'google' in ithe
> OAuth api; it is just hosted in the labs-google repo. This means most
> users won't be affected, as the Maven coordinates won't change.
>
>
> I.
>
>
>
>
> [1]
> https://developers.digitalocean.com/documentation/changelog/api-v1/sunsetting-api-v1/