Open Stack

On Sunday, April 19, 2015, Tim Bell <Tim.Bell at cern.ch> wrote:

> > -----Original Message-----
> > From: Morgan Fainberg [mailto:morgan.fainberg at gmail.com <javascript:;>]
> > Sent: 18 April 2015 05:20
> > To: OpenStack Development Mailing List
> > Subject: [openstack-dev] [keystone] keystone middleware package changing
> > release method in Liberty
> >
> > 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).
> >
>
> Will this require that the keystonemiddleware is upgraded at the same as
> the Keystone server across a cloud or at the same time as services such as
> Nova ?
>
> Many sites do a component based staged upgrade. This would mean an
> approach such as upgrading ceilometer or cinder to Liberty significantly
> before the Nova upgrade with Keystone in the  middle.
>
> - Would the new keystonemiddleware work with the old Keystone version ?
> - How would multi-service controllers be upgraded where services such as
> Nova and cinder controllers share the same server ?
>
>
Keystonemiddleware will work with different versions of keystone. It will
be coupled to the requirements for nova/glance/etc (and have tags for the
milestones for the named release). The stability of keystone's APIs and how
middleware communicates to keystone will not change. We may have 2-cycle
deprecation of  lingering unused features.

This is strictly that we will be doing following the release schedule of
the server projects not changing stability or interoperability. With the
exception of potentially doing a 2-cycle deprecation of un-used features
(as mentioned above).


--Morgan


> > 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.
> >
> > Cheers,
> > Morgan
> >
> >
> > [1] Note: keystonemiddleware was not used by the integrated release
> until Juno.
> >
> > Sent via mobile
> > _________________________________________________________________
> > _________
> > 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
>
> __________________________________________________________________________
> 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/f1b3089e/attachment.html>