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

Sean Dague sean at dague.net
Mon Apr 20 11:19:50 UTC 2015


On 04/19/2015 12:54 PM, Morgan Fainberg wrote:
> 
> 
> On Sunday, April 19, 2015, Robert Collins <robertc at robertcollins.net
> <mailto: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.

Ok, specific scenario question:

I have Neutron API, Nova API, and Cinder API on one API controller box
in Kilo.

What is the expected upgrade strategy?

Will L1, L2, L3 publish to pypi?

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list