[openstack-dev] [keystone] keystone middleware package changing release method in Liberty
robertc at robertcollins.net
Sun Apr 19 08:12:12 UTC 2015
On 18 April 2015 at 15:20, Morgan Fainberg <morgan.fainberg at gmail.com> wrote:
> Hi everyone,
> I wanted to communicate to the community that the Keystone development team has determined that keystonemiddleware package should no longer be released in the same manner as the client libraries. Instead we will be releasing keystonemiddleware in the same manner as Keystone, in the coordinated style.
> There are a number of reasons but the largest factor is coordinating the requirements. Since keystonemiddleware runs in the process space / interpreter for the services (e.g. Nova) there is no expectation that the version of keystonemiddleware from Juno will run in Liberty nova (or vice versa).
> With this in mind we will be updating all of the testing and gating to make keystonemiddleware conform in the same manner as the services that utilize it. This change will start with the Liberty release cycle. Kilo and previous releases of OpenStack will continue to rely on the 1.x.x semver releases that mirror the stable/xxx branches of keystonemiddleware.
> Version numbers and other choices related to this change will be discussed with the Release Management team and updated during the Liberty cycle. This will not impact or change our support plans for the kilo or Juno releases / associated versions of keystonemiddleware. (Full support and maintenance is planned for the lifespan of Juno and Kilo releases).
> Please feel free to respond in this thread or speak with us on IRC if you have questions of concerns about this change.
So how will one match versions between CD deployed Nova and
keystonemiddleware? You won't be able to specify what versions work
and don't, will you?
This concerns me precisely because it runs in the process - there's an
expectation of API stability across external API's, but internally
things tend to be rather more rocky. In TripleO we regularly ran into
servers depending on un-released client library changes, for instance.
This will be better than that was, but only because its being
explicitly documented as such.
Could you enlarge on what 'coordinating the requirements' means?
Robert Collins <rbtcollins at hp.com>
HP Converged Cloud
More information about the OpenStack-dev