<br><br>On Sunday, April 19, 2015, Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 18 April 2015 at 15:20, Morgan Fainberg <<a href="javascript:;" onclick="_e(event, 'cvml', 'morgan.fainberg@gmail.com')">morgan.fainberg@gmail.com</a>> wrote:<br>
> Hi everyone,<br>
><br>
> 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.<br>
><br>
> 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).<br>
><br>
> 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.<br>
><br>
> 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]<br>
><br>
> Please feel free to respond in this thread or speak with us on IRC if you have questions of concerns about this change.<br>
<br>
So how will one match versions between CD deployed Nova and<br>
keystonemiddleware? You won't be able to specify what versions work<br>
and don't, will you?<br>
<br>
This concerns me precisely because it runs in the process - there's an<br>
expectation of API stability across external API's, but internally<br>
things tend to be rather more rocky. In TripleO we regularly ran into<br>
servers depending on un-released client library changes, for instance.<br>
<br>
This will be better than that was, but only because its being<br>
explicitly documented as such.<br>
<br>
Could you enlarge on what 'coordinating the requirements' means?<br>
<br></blockquote><div><br></div><div>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. </div><div><br></div><div>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,</div>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). <div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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<span></span> discussion.<br><div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-Rob<br>
<br>
<br>
--<br>
Robert Collins <<a href="javascript:;" onclick="_e(event, 'cvml', 'rbtcollins@hp.com')">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<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></div></div></div>