You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Andrew Phillips <an...@apache.org> on 2014/07/30 14:39:13 UTC
[DISCUSS] Release Apache jclouds 1.8.0 RC1
This thread is for discussion of the first release candidate for
Apache jclouds 1.8.0. Please use this thread for discussion of issues
uncovered in the RC, questions you may have about the RC, etc. Thank
you.
Regards
ap
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Is there anything I can do to help validate the release? Obviously
> I can run the live tests for familiar providers such as HP and GCE,
> etc.
Live tests are best - if you could run those, that would be great.
Otherwise, if you could check that all the JIRA issues you expect to
be in 1.8.0 are in the correct state in JIRA, that would be useful,
too...but it's more of a housekeeping issue, I'd say. Far less
important than tests.
Thanks!
ap
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Andrew Phillips <ap...@qrmedia.com>.
> @Andrew could you please remove it as it is just an error?
Sure! Thanks for clarifying:
https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;a=commit;h=a81d8aeb2a5ce3b3a552f311de6b8c5a5c79fba8
Depending on what happens with RC1, we'll include this in 1.8.0, or
will merge to 1.8.x afterwards.
ap
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Andrea Turli <an...@gmail.com>.
Sorry about that guys, not sure how that happened.
@Andrew could you please remove it as it is just an error?
Thanks,
Andrea
On 7/31/14, Andrew Phillips <ap...@qrmedia.com> wrote:
> I notice we now have a "dockerFile" in the root of jclouds-labs [1].
> I'm pretty sure that doesn't belong there?
>
> I don't think it should block the release, but it would be good to
> move it to the right place or get rid of it.
>
> @Andrea: or does it need to be there?
>
> Regards
>
> ap
>
> [1] https://github.com/jclouds/jclouds-labs/blob/master/dockerFile
>
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Andrew Phillips <ap...@qrmedia.com>.
I notice we now have a "dockerFile" in the root of jclouds-labs [1].
I'm pretty sure that doesn't belong there?
I don't think it should block the release, but it would be good to
move it to the right place or get rid of it.
@Andrea: or does it need to be there?
Regards
ap
[1] https://github.com/jclouds/jclouds-labs/blob/master/dockerFile
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Chris Custine <ch...@gmail.com>.
Is there anything I can do to help validate the release? Obviously I can run the live tests for familiar providers such as HP and GCE, etc. against the RC binaries, but I’m wondering if there is anything else that would be helpful since I have some time today.
-Chris
--
Chris Custine
On July 31, 2014 at 11:15:45 AM, Everett Toews (everett.toews@rackspace.com) wrote:
> I’ve readded jclouds-chef to the script and everything ran fine.
>
> Thanks,
> Everett
>
>
> On Jul 31, 2014, at 12:48 AM, Ignasi Barrera wrote:
>
> > Yep, I discussed this on IRC after you left and reverted the chef commit
> > before Andrew started the release. I preferred to do so due to some karaf
> > failures in tge karaf PR, to avoid having to diagnose karaf stuff during
> > the release. I left the details in a comment in the PR.
> >
> > If you re-enable and build chef you should be able to build everything.
> > El 31/07/2014 00:56, "Everett Toews" escribió:
> >
> >> I updated verify_jclouds_rc.sh [1] to remove jclouds-chef but when I run
> >> it I get the error:
> >>
> >> [ERROR] Failed to execute goal on project core: Could not resolve
> >> dependencies for project org.apache.jclouds.karaf.chef:core:jar:1.8.0:
> >> Could not find artifact org.apache.jclouds.api:chef:jar:1.8.0 in sonatype
> >>
> >> Is there a dependency in karaf that missed getting updated or does the
> >> script need to do something different now?
> >>
> >> Everett
> >>
> >> [1] https://dist.apache.org/repos/dist/dev/jclouds/verify_jclouds_rc.sh
> >>
> >>
> >> On Jul 30, 2014, at 7:39 AM, Andrew Phillips wrote:
> >>
> >>> This thread is for discussion of the first release candidate for Apache
> >> jclouds 1.8.0. Please use this thread for discussion of issues uncovered in
> >> the RC, questions you may have about the RC, etc. Thank you.
> >>>
> >>> Regards
> >>>
> >>> ap
> >>
> >>
>
>
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Everett Toews <ev...@RACKSPACE.COM>.
I’ve readded jclouds-chef to the script and everything ran fine.
Thanks,
Everett
On Jul 31, 2014, at 12:48 AM, Ignasi Barrera <na...@apache.org> wrote:
> Yep, I discussed this on IRC after you left and reverted the chef commit
> before Andrew started the release. I preferred to do so due to some karaf
> failures in tge karaf PR, to avoid having to diagnose karaf stuff during
> the release. I left the details in a comment in the PR.
>
> If you re-enable and build chef you should be able to build everything.
> El 31/07/2014 00:56, "Everett Toews" <ev...@rackspace.com> escribió:
>
>> I updated verify_jclouds_rc.sh [1] to remove jclouds-chef but when I run
>> it I get the error:
>>
>> [ERROR] Failed to execute goal on project core: Could not resolve
>> dependencies for project org.apache.jclouds.karaf.chef:core:jar:1.8.0:
>> Could not find artifact org.apache.jclouds.api:chef:jar:1.8.0 in sonatype
>>
>> Is there a dependency in karaf that missed getting updated or does the
>> script need to do something different now?
>>
>> Everett
>>
>> [1] https://dist.apache.org/repos/dist/dev/jclouds/verify_jclouds_rc.sh
>>
>>
>> On Jul 30, 2014, at 7:39 AM, Andrew Phillips <an...@apache.org> wrote:
>>
>>> This thread is for discussion of the first release candidate for Apache
>> jclouds 1.8.0. Please use this thread for discussion of issues uncovered in
>> the RC, questions you may have about the RC, etc. Thank you.
>>>
>>> Regards
>>>
>>> ap
>>
>>
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Ignasi Barrera <na...@apache.org>.
Yep, I discussed this on IRC after you left and reverted the chef commit
before Andrew started the release. I preferred to do so due to some karaf
failures in tge karaf PR, to avoid having to diagnose karaf stuff during
the release. I left the details in a comment in the PR.
If you re-enable and build chef you should be able to build everything.
El 31/07/2014 00:56, "Everett Toews" <ev...@rackspace.com> escribió:
> I updated verify_jclouds_rc.sh [1] to remove jclouds-chef but when I run
> it I get the error:
>
> [ERROR] Failed to execute goal on project core: Could not resolve
> dependencies for project org.apache.jclouds.karaf.chef:core:jar:1.8.0:
> Could not find artifact org.apache.jclouds.api:chef:jar:1.8.0 in sonatype
>
> Is there a dependency in karaf that missed getting updated or does the
> script need to do something different now?
>
> Everett
>
> [1] https://dist.apache.org/repos/dist/dev/jclouds/verify_jclouds_rc.sh
>
>
> On Jul 30, 2014, at 7:39 AM, Andrew Phillips <an...@apache.org> wrote:
>
> > This thread is for discussion of the first release candidate for Apache
> jclouds 1.8.0. Please use this thread for discussion of issues uncovered in
> the RC, questions you may have about the RC, etc. Thank you.
> >
> > Regards
> >
> > ap
>
>
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Everett Toews <ev...@RACKSPACE.COM>.
I updated verify_jclouds_rc.sh [1] to remove jclouds-chef but when I run it I get the error:
[ERROR] Failed to execute goal on project core: Could not resolve dependencies for project org.apache.jclouds.karaf.chef:core:jar:1.8.0: Could not find artifact org.apache.jclouds.api:chef:jar:1.8.0 in sonatype
Is there a dependency in karaf that missed getting updated or does the script need to do something different now?
Everett
[1] https://dist.apache.org/repos/dist/dev/jclouds/verify_jclouds_rc.sh
On Jul 30, 2014, at 7:39 AM, Andrew Phillips <an...@apache.org> wrote:
> This thread is for discussion of the first release candidate for Apache jclouds 1.8.0. Please use this thread for discussion of issues uncovered in the RC, questions you may have about the RC, etc. Thank you.
>
> Regards
>
> ap
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Andrew Phillips <ap...@qrmedia.com>.
We could close the vote now but I'd rather wait until tomorrow morning
to see if there's any further discussion around the issues uncovered
today, or if anyone else is able to review (we only have 3 votes so
far).
I'm in CET so won't be able to follow the discussion today, but will
review tomorrow morning here.
Thanks!
ap
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Everett Toews <ev...@RACKSPACE.COM>.
On Aug 4, 2014, at 7:04 PM, Andrew Gaul <ga...@apache.org>> wrote:
Further, if we are going to change the
default, can we align with other language bindings like fog?
+1
fog deprecated default region support over 6 months ago. They’re going to be removing it completely now. [1]
Everett
[1] https://github.com/fog/fog/issues/3091
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Andrew Gaul <ga...@apache.org>.
On Mon, Aug 04, 2014 at 03:38:56PM -0600, Chris Custine wrote:
> > Ideally jclouds should follow the best practice of whatever HP
> > recommends and what other language bindings implement. We should not
> > gratuitously change the defaults; if I understand it correctly, we will
> > impose three transitions to users of the default region:
> >
> > 1.7.3 swift = default region region-a.geo-1
> > 1.8.0 swift = default region region-b.geo-1
> > 1.8.1 swift = default region changes back to region-a.geo-1?
> > openstack-swift = error without default region
> >
> > How can we minimize this pain?
>
> In a nutshell, the previous behavior of selecting the first region was more of an accident due to the way HP lists its object storage endpoint versions. The default endpoint selection in the keystone provider and other overrides is to pick the last matching endpoint where service type and version match[1][2][3]. The HP parent SwiftApiMetdata version is “1.0", and HP has region-a as “1.0” but region-b as “1” in keystone (they are aware of this but I have been told it is unlikely to be changed), so as a consequence, this logic always returned region-a which happens to be first. It also meant that you could never talk to region-b because it would never match the version. My fixes for the HP provider are currently ignoring api version when it matches so that you can actually talk to region-b if you want to. As a side effect, the intended behavior works and if you don’t specify region it returns the last one just like all other openstack providers.
>
> So having said all of that, I am fine with returning the old (broken) behavior if that is the community consensus, but I wanted to present the facts and make sure that this fix wasn’t seen as gratuitously changing defaults or otherwise having a disregard for impact on users.
>
> If this is a lone blocker, I also take ownership and volunteer to cut the next RC if it is necessary. :-)
While I appreciate the technical background on this issue, I am more
worried about the user experience. Can you address my question about
how many times we plan to change the default region for users? Most
hpcloud-objectstorage users likely use the default and will find
multiple changes confusing. Further, if we are going to change the
default, can we align with other language bindings like fog?
--
Andrew Gaul
http://gaul.org/
RE: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Zack Shoylev <za...@RACKSPACE.COM>.
Throwing an error seems to make the most sense for now.
Having jclouds pick what amounts to a random region seems worse than failing forward and throwing an error.
________________________________________
From: Andrew Gaul [gaul@apache.org]
Sent: Monday, August 04, 2014 7:26 PM
To: dev@jclouds.apache.org
Subject: Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
On Mon, Aug 04, 2014 at 11:47:03PM +0200, Andrew Phillips wrote:
> I understand Andrew G's point about minimizing disruption for users,
> but if I get this correctly (and I'm hardly the expert here) the
> behaviour so far has simply been broken.
> If we can document a way in the examples and/or release notes to
> allow people to easily continue with the old behaviour if they wish,
> that would be helpful. And obviously, it would be good to clarify if
> we are confident that this behaviour won't change *again* with the
> change to openstack-swift soon.
While we could quibble over the existing broken behavior, changing the
default from the first region to the last region is more broken. Even
if we accept that users of the default region-a will now store blobs in
region-b, if HP Cloud introduces region-c, jclouds will store data in it
depending on the ordering that the openstack catalog provides! Instead
we should define a default region or throw an error without a default.
--
Andrew Gaul
http://gaul.org/
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Andrew Gaul <ga...@apache.org>.
On Mon, Aug 04, 2014 at 11:47:03PM +0200, Andrew Phillips wrote:
> I understand Andrew G's point about minimizing disruption for users,
> but if I get this correctly (and I'm hardly the expert here) the
> behaviour so far has simply been broken.
> If we can document a way in the examples and/or release notes to
> allow people to easily continue with the old behaviour if they wish,
> that would be helpful. And obviously, it would be good to clarify if
> we are confident that this behaviour won't change *again* with the
> change to openstack-swift soon.
While we could quibble over the existing broken behavior, changing the
default from the first region to the last region is more broken. Even
if we accept that users of the default region-a will now store blobs in
region-b, if HP Cloud introduces region-c, jclouds will store data in it
depending on the ordering that the openstack catalog provides! Instead
we should define a default region or throw an error without a default.
--
Andrew Gaul
http://gaul.org/
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Andrew Phillips <ap...@qrmedia.com>.
> If this is a lone blocker, I also take ownership and volunteer to
> cut the next RC if it is necessary. :-)
I personally don't see this as a blocker right now, but of course
thanks for stepping up!
I understand Andrew G's point about minimizing disruption for users,
but if I get this correctly (and I'm hardly the expert here) the
behaviour so far has simply been broken.
If we can document a way in the examples and/or release notes to allow
people to easily continue with the old behaviour if they wish, that
would be helpful. And obviously, it would be good to clarify if we are
confident that this behaviour won't change *again* with the change to
openstack-swift soon.
ap
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Chris Custine <ch...@gmail.com>.
> Ideally jclouds should follow the best practice of whatever HP
> recommends and what other language bindings implement. We should not
> gratuitously change the defaults; if I understand it correctly, we will
> impose three transitions to users of the default region:
>
> 1.7.3 swift = default region region-a.geo-1
> 1.8.0 swift = default region region-b.geo-1
> 1.8.1 swift = default region changes back to region-a.geo-1?
> openstack-swift = error without default region
>
> How can we minimize this pain?
In a nutshell, the previous behavior of selecting the first region was more of an accident due to the way HP lists its object storage endpoint versions. The default endpoint selection in the keystone provider and other overrides is to pick the last matching endpoint where service type and version match[1][2][3]. The HP parent SwiftApiMetdata version is “1.0", and HP has region-a as “1.0” but region-b as “1” in keystone (they are aware of this but I have been told it is unlikely to be changed), so as a consequence, this logic always returned region-a which happens to be first. It also meant that you could never talk to region-b because it would never match the version. My fixes for the HP provider are currently ignoring api version when it matches so that you can actually talk to region-b if you want to. As a side effect, the intended behavior works and if you don’t specify region it returns the last one just like all other openstack providers.
So having said all of that, I am fine with returning the old (broken) behavior if that is the community consensus, but I wanted to present the facts and make sure that this fix wasn’t seen as gratuitously changing defaults or otherwise having a disregard for impact on users.
If this is a lone blocker, I also take ownership and volunteer to cut the next RC if it is necessary. :-)
Thanks,
Chris
[1] http://git.io/HU-xZA
[2] http://git.io/lUfDiw
[3] http://git.io/QoWKuw
--
Chris Custine
On August 4, 2014 at 11:34:51 AM, Andrew Gaul (gaul@apache.org) wrote:
> On Mon, Aug 04, 2014 at 10:37:08AM -0600, Chris Custine wrote:
> > > > HP should either have a default region for all language bindings
> > >
> > > @Chris: Would that work? If so, which region would make most sense?
> >
> > If the desire is to set a default that matches the original region-a.geo-1 endpoint,
> then yes I think this would be the ONLY way to achieve it consistently. One of the problems
> with using first or last is that either one of them can change at any time depending on how
> keystone returns the endpoints list (adding a new region, for instance). My preference
> would be to force a caller to explicitly specify a region, but I think that will be the case
> anyway when we migrate to the new swift api provider from labs.
> >
> > Should I work this in to 1.8.1-SNAPSHOT later this week?
>
> Ideally jclouds should follow the best practice of whatever HP
> recommends and what other language bindings implement. We should not
> gratuitously change the defaults; if I understand it correctly, we will
> impose three transitions to users of the default region:
>
> 1.7.3 swift = default region region-a.geo-1
> 1.8.0 swift = default region region-b.geo-1
> 1.8.1 swift = default region changes back to region-a.geo-1?
> openstack-swift = error without default region
>
> How can we minimize this pain?
>
> --
> Andrew Gaul
> http://gaul.org/
>
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Andrew Gaul <ga...@apache.org>.
On Mon, Aug 04, 2014 at 10:37:08AM -0600, Chris Custine wrote:
> > > HP should either have a default region for all language bindings
> >
> > @Chris: Would that work? If so, which region would make most sense?
>
> If the desire is to set a default that matches the original region-a.geo-1 endpoint, then yes I think this would be the ONLY way to achieve it consistently. One of the problems with using first or last is that either one of them can change at any time depending on how keystone returns the endpoints list (adding a new region, for instance). My preference would be to force a caller to explicitly specify a region, but I think that will be the case anyway when we migrate to the new swift api provider from labs.
>
> Should I work this in to 1.8.1-SNAPSHOT later this week?
Ideally jclouds should follow the best practice of whatever HP
recommends and what other language bindings implement. We should not
gratuitously change the defaults; if I understand it correctly, we will
impose three transitions to users of the default region:
1.7.3 swift = default region region-a.geo-1
1.8.0 swift = default region region-b.geo-1
1.8.1 swift = default region changes back to region-a.geo-1?
openstack-swift = error without default region
How can we minimize this pain?
--
Andrew Gaul
http://gaul.org/
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Chris Custine <ch...@gmail.com>.
> > HP should either have a default region for all language bindings
>
> @Chris: Would that work? If so, which region would make most sense?
If the desire is to set a default that matches the original region-a.geo-1 endpoint, then yes I think this would be the ONLY way to achieve it consistently. One of the problems with using first or last is that either one of them can change at any time depending on how keystone returns the endpoints list (adding a new region, for instance). My preference would be to force a caller to explicitly specify a region, but I think that will be the case anyway when we migrate to the new swift api provider from labs.
Should I work this in to 1.8.1-SNAPSHOT later this week?
Thanks,
Chris
--
Chris Custine
On August 4, 2014 at 1:23:26 AM, Andrew Phillips (aphillips@qrmedia.com) wrote:
> > We did not unhook google-cloud-storage from the release; not a release
> > blocker but this could confuse users.
>
> Just to clarify: you mean we should probably *not* have released this?
>
> > HP should either have a default region for all language bindings
>
> @Chris: Would that work? If so, which region would make most sense?
>
> > Also we have not changed master from 1.8.0-SNAPSHOT to 2.0.0-SNAPSHOT.
>
> Thanks for the reminder. I have that commit waiting locally and am
> planning to push it when the release goes out, although since we're
> making a new branch there's actually not really a need for that.
>
> Everyone OK for 2.0.0-SNAPSHOT for master?
>
> Thanks for verifying and voting, Andrew G!
>
> ap
>
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Everett Toews <ev...@RACKSPACE.COM>.
On Aug 4, 2014, at 2:22 AM, Andrew Phillips <ap...@qrmedia.com> wrote:
> Everyone OK for 2.0.0-SNAPSHOT for master?
+1
Everett
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Andrew Gaul <ga...@apache.org>.
On Mon, Aug 04, 2014 at 10:29:43PM +0200, Andrew Phillips wrote:
> >I will unhook it from 1.8.x branch after release; is there any way to
> >remove this single artifact from the release?
>
> Well, we can delete it from the staging repo, but that it'll be a
> little out of sync with the root POM [1] *and* the src and dist
> bundles, so I'm not sure if that's advisable.
>
> Or we could add a note to the release notes describing the
> limitation and recommending to use this provider only with caution,
> or not at all.
I do not see the accidental inclusion of a jar as a reason another
release candidate. I will update the release notes to reflect that we
do not recommend its use.
--
Andrew Gaul
http://gaul.org/
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Andrew Phillips <ap...@qrmedia.com>.
> I will unhook it from 1.8.x branch after release; is there any way to
> remove this single artifact from the release?
Well, we can delete it from the staging repo, but that it'll be a
little out of sync with the root POM [1] *and* the src and dist
bundles, so I'm not sure if that's advisable.
Or we could add a note to the release notes describing the limitation
and recommending to use this provider only with caution, or not at all.
Thoughts?
ap
[1] https://github.com/jclouds/jclouds-labs-google/blob/master/pom.xml#L59
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Andrew Gaul <ga...@apache.org>.
On Mon, Aug 04, 2014 at 09:22:46AM +0200, Andrew Phillips wrote:
> Andrew Gaul wrote:
> >We did not unhook google-cloud-storage from the release; not a release
> >blocker but this could confuse users.
>
> Just to clarify: you mean we should probably *not* have released this?
The current google-cloud-storage implementation can only operate on
buckets, not objects. We should not have released it as I recommended
earlier:
http://mail-archives.apache.org/mod_mbox/jclouds-dev/201407.mbox/%3C20140728075325.GC26295@sherlock%3E
I will unhook it from 1.8.x branch after release; is there any way to
remove this single artifact from the release?
> >Also we have not changed master from 1.8.0-SNAPSHOT to 2.0.0-SNAPSHOT.
>
> Thanks for the reminder. I have that commit waiting locally and am
> planning to push it when the release goes out, although since we're
> making a new branch there's actually not really a need for that.
>
> Everyone OK for 2.0.0-SNAPSHOT for master?
2.0.0-SNAPSHOT is OK.
--
Andrew Gaul
http://gaul.org/
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Andrew Phillips <ap...@qrmedia.com>.
> We did not unhook google-cloud-storage from the release; not a release
> blocker but this could confuse users.
Just to clarify: you mean we should probably *not* have released this?
> HP should either have a default region for all language bindings
@Chris: Would that work? If so, which region would make most sense?
> Also we have not changed master from 1.8.0-SNAPSHOT to 2.0.0-SNAPSHOT.
Thanks for the reminder. I have that commit waiting locally and am
planning to push it when the release goes out, although since we're
making a new branch there's actually not really a need for that.
Everyone OK for 2.0.0-SNAPSHOT for master?
Thanks for verifying and voting, Andrew G!
ap
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Andrew Gaul <ga...@apache.org>.
On Sun, Aug 03, 2014 at 11:39:15PM -0700, Andrew Gaul wrote:
> On Wed, Jul 30, 2014 at 02:39:13PM +0200, Andrew Phillips wrote:
> > This thread is for discussion of the first release candidate for
> > Apache jclouds 1.8.0. Please use this thread for discussion of
> > issues uncovered in the RC, questions you may have about the RC,
> > etc. Thank you.
>
> I attached integration test results from atmosonline, aws-s3, azureblob,
> and cloudfiles-us. These had some transient failures and I needed to
> run tests multiple times. Comments on specific issues:
>
> JCLOUDS-641: rackspace-cloudfiles-us integration tests fail
>
> This need not block 1.8.0, but must-fix for 1.8.1. 1/3 of the
> integration tests failing is a much poorer result than any of the
> existing providers.
>
> JCLOUDS-645: Incorrect endpoint url chosen for default region of HPCloud
> Object Storage
>
> Defer to Chris from HP but changing the default region will confuse
> users. HP should either have a default region for all language bindings
> (like AWS S3 us-standard) or raise an error without an explicit region
> as Everett suggested. What does fog do in this circumstance?
We did not unhook google-cloud-storage from the release; not a release
blocker but this could confuse users.
Also we have not changed master from 1.8.0-SNAPSHOT to 2.0.0-SNAPSHOT.
--
Andrew Gaul
http://gaul.org/
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Andrew Gaul <ga...@apache.org>.
On Wed, Jul 30, 2014 at 02:39:13PM +0200, Andrew Phillips wrote:
> This thread is for discussion of the first release candidate for
> Apache jclouds 1.8.0. Please use this thread for discussion of
> issues uncovered in the RC, questions you may have about the RC,
> etc. Thank you.
I attached integration test results from atmosonline, aws-s3, azureblob,
and cloudfiles-us. These had some transient failures and I needed to
run tests multiple times. Comments on specific issues:
JCLOUDS-641: rackspace-cloudfiles-us integration tests fail
This need not block 1.8.0, but must-fix for 1.8.1. 1/3 of the
integration tests failing is a much poorer result than any of the
existing providers.
JCLOUDS-645: Incorrect endpoint url chosen for default region of HPCloud
Object Storage
Defer to Chris from HP but changing the default region will confuse
users. HP should either have a default region for all language bindings
(like AWS S3 us-standard) or raise an error without an explicit region
as Everett suggested. What does fog do in this circumstance?
--
Andrew Gaul
http://gaul.org/
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Shrinand Javadekar <sh...@maginatics.com>.
I am in the process of verifying the release. I ran into some issues
with the deprecated methods and have fixed them (at least the code
compiles). Will run tests against well known blobstores and report the
results.
On Wed, Jul 30, 2014 at 5:39 AM, Andrew Phillips <an...@apache.org> wrote:
> This thread is for discussion of the first release candidate for Apache
> jclouds 1.8.0. Please use this thread for discussion of issues uncovered in
> the RC, questions you may have about the RC, etc. Thank you.
>
> Regards
>
> ap
Re: [DISCUSS] Release Apache jclouds 1.8.0 RC1
Posted by Chris Custine <ch...@gmail.com>.
I have run the following live tests over the weekend and some have failures explained below:
hpcloud-objectstorage - ok
hpcloud-blockstorage - ok
google-cloud-storage - ok
hpcloud-compute - fails a single negative templatebuilder test due to a new image on the provider that suddenly matches
google-compute-engine - Several live test failures due to test configurations, provider itself passes with https://github.com/jclouds/jclouds-labs-google/pull/37
So the only failures I can see are actually caused by test code problems or the recurring issue of provider images changing and borking live tests. I assume that is acceptable for a release given the dynamic nature of the live tests?
Thanks,
Chris
--
Chris Custine
On July 30, 2014 at 7:01:04 AM, Andrew Phillips (andrewp@apache.org) wrote:
> This thread is for discussion of the first release candidate for
> Apache jclouds 1.8.0. Please use this thread for discussion of issues
> uncovered in the RC, questions you may have about the RC, etc. Thank
> you.
>
> Regards
>
> ap
>