<br><br>On Monday, April 20, 2015, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/20/2015 11:20 AM, Morgan Fainberg wrote:<br>
><br>
><br>
> On Monday, April 20, 2015, Sean Dague <<a href="javascript:;" onclick="_e(event, 'cvml', 'sean@dague.net')">sean@dague.net</a><br>
> <mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'sean@dague.net')">sean@dague.net</a>>> wrote:<br>
><br>
> On 04/19/2015 12:54 PM, Morgan Fainberg wrote:<br>
> ><br>
> ><br>
> > On Sunday, April 19, 2015, Robert Collins<br>
> <<a href="javascript:;" onclick="_e(event, 'cvml', 'robertc@robertcollins.net')">robertc@robertcollins.net</a> <javascript:;><br>
> > <mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'robertc@robertcollins.net')">robertc@robertcollins.net</a> <javascript:;>>> wrote:<br>
> ><br>
> > On 18 April 2015 at 15:20, Morgan Fainberg<br>
> > <<a href="javascript:;" onclick="_e(event, 'cvml', 'morgan.fainberg@gmail.com')">morgan.fainberg@gmail.com</a> <javascript:;> <javascript:;>> wrote:<br>
> > > Hi everyone,<br>
> > ><br>
> > > I wanted to communicate to the community that the Keystone<br>
> > development team has determined that keystonemiddleware package<br>
> > should no longer be released in the same manner as the client<br>
> > libraries. Instead we will be releasing keystonemiddleware in the<br>
> > same manner as Keystone, in the coordinated style.<br>
> > ><br>
> > > There are a number of reasons but the largest factor is<br>
> > coordinating the requirements. Since keystonemiddleware runs<br>
> in the<br>
> > process space / interpreter for the services (e.g. Nova) there<br>
> is no<br>
> > expectation that the version of keystonemiddleware from Juno will<br>
> > run in Liberty nova (or vice versa).<br>
> > ><br>
> > > With this in mind we will be updating all of the testing and<br>
> > gating to make keystonemiddleware conform in the same manner<br>
> as the<br>
> > services that utilize it. This change will start with the Liberty<br>
> > release cycle. Kilo and previous releases of OpenStack will<br>
> continue<br>
> > to rely on the 1.x.x semver releases that mirror the stable/xxx<br>
> > branches of keystonemiddleware.<br>
> > ><br>
> > > Version numbers and other choices related to this change will be<br>
> > discussed with the Release Management team and updated during the<br>
> > Liberty cycle. This will not impact or change our support<br>
> plans for<br>
> > the kilo or Juno releases / associated versions of<br>
> > keystonemiddleware. (Full support and maintenance is planned<br>
> for the<br>
> > lifespan of Juno and Kilo releases).[1]<br>
> > ><br>
> > > Please feel free to respond in this thread or speak with us<br>
> on IRC<br>
> > 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<br>
> work<br>
> > and don't, will you?<br>
> ><br>
> > This concerns me precisely because it runs in the process -<br>
> 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<br>
> ran into<br>
> > servers depending on un-released client library changes, for<br>
> 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>
> ><br>
> > This is simply a choice to adhere to the global-requirements for a<br>
> given<br>
> > release (e.g. Liberty) that nova (and other projects) adhere to. We<br>
> > won't be doing "a release when we feel like it" we will be doing a<br>
> > standard mile-stone tag for (example) L1, L2, L3, and Liberty<br>
> final. We<br>
> > will then maintain the backport for stable/Liberty for the life of the<br>
> > release.<br>
> ><br>
> > Those doing CD (or near CD) should be unaffected unless we do<br>
> something<br>
> > terrible and broken (which could happen but warrants an immediate<br>
> > fix/revert). Keystonemiddleware thankfully has almost no "public APIs"<br>
> > it receives a header,<br>
> > Validates the token, then returns headers (the "public" part) to the<br>
> > underlying service. The expectation is CD deployed should work<br>
> *unless*<br>
> > one of the two projects suddenly has a dependency conflict. Obviously<br>
> > middleware needs to see testing with minimum versions from<br>
> > global-requirements not just maximums (like all projects need).<br>
> ><br>
> > Today middleware is released independent of everything (like a client)<br>
> > but since it is tightly coupled to a set of requirements using 1.5.x<br>
> > with Juno is challenging, since there is a requirements mismatch.<br>
> Today<br>
> > the only way you know what versions work is by either looking at<br>
> release<br>
> > dates or by trial/error (or examining requirements). I think it is far<br>
> > better to release middleware like a server project to more clearly<br>
> > indicate release schedule and compatibility.<br>
> ><br>
> > Knowing that 1.3.x receives backports (and tied to Juno), but 1.4.x<br>
> > doesn't because it was released between Juno and kilo, and 1.5.x does<br>
> > again (and is tied to kilo) is just a poor experience for our<br>
> deployers.<br>
> > I don't want to have to name some release LTS of keystonemiddleware,<br>
> > let's release in a way that make sense for how it is used.<br>
> ><br>
> > Details of the version numbers will be hashed out at the summit<br>
> and the<br>
> > release management team. (E.g do we move to a 2015.x.x model? Do we<br>
> > increment the X per release in semver, or the 'y'?) This part is<br>
> not yet<br>
> > determined and requires some discussion.<br>
><br>
> Ok, specific scenario question:<br>
><br>
> I have Neutron API, Nova API, and Cinder API on one API controller box<br>
> in Kilo.<br>
><br>
> What is the expected upgrade strategy?<br>
><br>
> Will L1, L2, L3 publish to pypi?<br>
><br>
><br>
> Upgrade strategy will be the same as upgrading any api on that box. If<br>
> you run venv for each, it is easy. If you run in the system installed<br>
> python path(s), you're chasing requirement conflicts the same as Juno -><br>
> Kilo.<br>
><br>
> Re publishing milestones: TBD. I wanted to discuss that with release<br>
> management team and see if that made sense. I believe it does make<br>
> sense, but have not determined that for sure.<br>
<br>
The reason I ask about releases, is that I'd like to keep the upstream<br>
gating release based (so it would consume the milestones) and not git<br>
HEAD based, because otherwise we're requiring code from an unreleased<br>
library, which lead us into some weird places.<br>
<br><br>
</blockquote><div><br></div><div>That is a enough reason to publish to pypi in my opinion. This may end up looking like and Oslo library in release planning (in general) but only released at the milestones (unless we have a reason to release for an emergency fix, etc)<span></span>. </div><div><br></div><div>--Morgan </div>