<br><br>On Sunday, April 19, 2015, Tim Bell <<a href="mailto:Tim.Bell@cern.ch">Tim.Bell@cern.ch</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> -----Original Message-----<br>
> From: Morgan Fainberg [mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'morgan.fainberg@gmail.com')">morgan.fainberg@gmail.com</a>]<br>
> Sent: 18 April 2015 05:20<br>
> To: OpenStack Development Mailing List<br>
> Subject: [openstack-dev] [keystone] keystone middleware package changing<br>
> release method in Liberty<br>
><br>
> Hi everyone,<br>
><br>
> I wanted to communicate to the community that the Keystone development<br>
> team has determined that keystonemiddleware package should no longer be<br>
> released in the same manner as the client libraries. Instead we will be releasing<br>
> keystonemiddleware in the same manner as Keystone, in the coordinated style.<br>
><br>
> There are a number of reasons but the largest factor is coordinating the<br>
> requirements. Since keystonemiddleware runs in the process space / interpreter<br>
> for the services (e.g. Nova) there is no expectation that the version of<br>
> keystonemiddleware from Juno will run in Liberty nova (or vice versa).<br>
><br>
<br>
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 ?<br>
<br>
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.<br>
<br>
- Would the new keystonemiddleware work with the old Keystone version ?<br>
- How would multi-service controllers be upgraded where services such as Nova and cinder controllers share the same server ?<br>
<br></blockquote><div><br></div><div>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. </div><div><br></div><div>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). </div><div><br></div><div><br></div>--Morgan <span></span><br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> With this in mind we will be updating all of the testing and gating to make<br>
> keystonemiddleware conform in the same manner as the services that utilize it.<br>
> This change will start with the Liberty release cycle. Kilo and previous releases of<br>
> OpenStack will continue to rely on the 1.x.x semver releases that mirror the<br>
> stable/xxx branches of keystonemiddleware.<br>
><br>
> Version numbers and other choices related to this change will be discussed with<br>
> the Release Management team and updated during the Liberty cycle. This will<br>
> not impact or change our support plans for the kilo or Juno releases / associated<br>
> versions of keystonemiddleware. (Full support and maintenance is planned for<br>
> the lifespan of Juno and Kilo releases).[1]<br>
><br>
> Please feel free to respond in this thread or speak with us on IRC if you have<br>
> questions of concerns about this change.<br>
><br>
> Cheers,<br>
> Morgan<br>
><br>
><br>
> [1] Note: keystonemiddleware was not used by the integrated release until Juno.<br>
><br>
> Sent via mobile<br>
> _________________________________________________________________<br>
> _________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>