> 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 (g...@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/ >
