[openstack-dev] [keystone] keystone middleware package changing release method in Liberty
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
> > 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?
> 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
> 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
What is the expected upgrade strategy?
Will L1, L2, L3 publish to pypi?
More information about the OpenStack-dev