On 24 June 2015 at 14:34, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2015-06-24 09:01:51 +0300 (+0300), Duncan Thomas wrote: >> The problem there is that it takes (significant) time for the connection >> attempt to time out - every cinder command taking several minutes is not >> acceptable. > [...] > > Another silly idea from an end user of cinderclient here, but try > both in parallel and use whichever responds first (abandoning the > other connection attempt at that point)? > > I just don't buy that we can consider new versions of the client > requiring existing deployments on still relevant releases to upgrade > to support it (either to a newer release, a patch, an additional > config option, some combination of the three). What we're going to > find instead is some (lots of?) providers updating their > documentation to tell users that they should stick with an older > cinderclient release indefinitely, and that's terrible from an > OpenStack interoperability standpoint.
The clients have always strived to have backwards compatibility, and this seems to be no different from the other scenarios that have been encountered. We've started to get away from that, and it feels like a mistake. As Jeremy points out, I fail to see why fallback default behaviour cannot be used.. Attempt to use version discovery feature, if fail - fall back to legacy behaviour.. What are the issues associated with this? Thanks -- Kind Regards, Dave Walker __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
