[openstack-dev] [keystone] keystone middleware package changing release method in Liberty

Morgan Fainberg morgan.fainberg at gmail.com
Sun Apr 19 16:54:55 UTC 2015

On Sunday, April 19, 2015, Robert Collins <robertc at robertcollins.net> wrote:

> On 18 April 2015 at 15:20, Morgan Fainberg <morgan.fainberg at gmail.com
> <javascript:;>> 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).[1]
> >
> > 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?
This is simply a choice to adhere to the global-requirements for a given
release (e.g. Liberty) that nova (and other projects) adhere to. We won't
be doing "a release when we feel like it" we will be doing a standard
mile-stone tag for (example) L1, L2, L3, and Liberty final. We will then
maintain the backport for stable/Liberty for the life of the release.

Those doing CD (or near CD) should be unaffected unless we do something
terrible and broken (which could happen but warrants an immediate
fix/revert). Keystonemiddleware thankfully has almost no "public APIs" it
receives a header,
Validates the token, then returns headers (the "public" part) to the
underlying service. The expectation is CD deployed should work *unless* one
of the two projects suddenly has a dependency conflict. Obviously
middleware needs to see testing with minimum versions from
global-requirements not just maximums (like all projects need).

Today middleware is released independent of everything (like a client) but
since it is tightly coupled to a set of requirements using 1.5.x with Juno
is challenging, since there is a requirements mismatch. Today the only way
you know what versions work is by either looking at release dates or by
trial/error (or examining requirements). I think it is far better to
release middleware like a server project to more clearly indicate release
schedule and compatibility.

Knowing that 1.3.x receives backports (and tied to Juno), but 1.4.x doesn't
because it was released between Juno and kilo, and 1.5.x does again (and is
tied to kilo) is just a poor experience for our deployers. I don't want to
have to name some release LTS of keystonemiddleware, let's  release in a
way that make sense for how it is used.

Details of the version numbers will be hashed out at the summit and the
release management team. (E.g do we move to a 2015.x.x model? Do we
increment the X per release in semver, or the 'y'?) This part is not yet
determined and requires some discussion.

> -Rob
> --
> Robert Collins <rbtcollins at hp.com <javascript:;>>
> Distinguished Technologist
> HP Converged Cloud
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150419/401ee52c/attachment.html>

More information about the OpenStack-dev mailing list