Open Stack

On 18 August 2015 at 13:08, Lucas Alvares Gomes <lucasagomes at gmail.com>
wrote:

> HI
>
> > Hi, I'd like to make sure I understand. Is it the case that ideally, if
> we
> > could go back in time, we'd like to change the client so it defaults to
> 1.1?
>
> AFAIUI, yes
>
> > But since we can't, the next client that we ship/release will have the
> most
> > reasonable oldest version? If so, then since the most recent client
> shipped
> > is at 1.6, then I think we should put it back to 1.6 even though it is
> 1.9
> > on master. Regardless of whether there are no backwards incompatible
> changes
> > between 1.6 & 1.9 -- because we need to stick to some
> way-of-doing-things,
> > and if we use 1.9, I suspect it will be confusing. At least 1.6 was what
> we
> > had at the end of kilo.
> >
>
> The reason why I think we should release with 1.9 is because:
>
> 1) It's already on master and people may be using it already
>
> 2) It's compatible with the previous version that has been released
> already (1.6).
>
> So it won't break neither users that just get it from pip nor users
> that clone the git repository.
>

The order of my preference is 1.1 (which is unrealistic as I mention
below), 1.6 (because that's what the client had in kilo release and is the
'closest' version to the server's 1.1), then 1.9 for the reasons you
mentioned above, then 1.10 just cuz it is the last version that is
backwards compatible :-)

Devananda has a patch[0] that changes the client to 1.6, but the reviewers'
comments there point to the mailing list (here) wrt deciding what it should
be so what do other folks think?


> > What we're saying is that for M*, N*, O*, ..., the version used in the
> > client will be the higher of server's MIN_VER_STR or 1.6, right?
> >
>
> It's a suggestion, if we all agree that the minimal version (1.1) is
> the ideal version to the client to be pinned with when no other
> version is specified, how can we best warn the users that we are going
> to pin to this version for the future releases ?
>
> Maybe we don't need to do that, but would be good to discuss and have
> a consensus about it.
>

 I think 1.1 (the server's MIN_VER_STR) is the ideal version for the
client, but I think we missed the boat on that. I don't think it makes much
sense to change things so that the client uses that version in some future
release. The reason being is that kilo was released with the client
defaulting to 1.6. For everyone in cloudland not explicitly specifying a
version, they are using 1.6. And what is different in 1.6 than 1.1 -- we
renamed NOSTATE to AVAILABLE state. I don't think it is worth breaking
existing applications to deprecate/go back to 1.1.

(A separate discussion I'd like to have, is when do we want to change the
server's MIN_VER_STR from 1.1 to eg 1.6 or even gasp, 1.11 when ENROLL made
its appearance).

--ruby

[0] https://review.openstack.org/#/c/208102/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150818/4d60f4dc/attachment.html>