Thanks. This addresses my concerns. Tim
From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com] Sent: 19 April 2015 18:34 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [keystone] keystone middleware package changing release method in Liberty On Sunday, April 19, 2015, Tim Bell <tim.b...@cern.ch<mailto:tim.b...@cern.ch>> wrote: > -----Original Message----- > From: Morgan Fainberg [mailto:morgan.fainb...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
