Open Stack

On Thu, Sep 22, 2016 at 04:25:00PM +1000, Tony Breeds wrote:
> On Wed, Sep 21, 2016 at 02:05:51PM -0400, Sean Dague wrote:
> 
> > Well, the risk profile of what has to be changed for stable/liberty
> > (given that all the actual code is buried in libraries which have tons
> > of other changes). Special cherry-picked library versions would be
> > needed to fix this without openning up a ton of risk for breaking
> > stable/liberty badly.
> > 
> > That is the bit of work that no one seems to really have picked up.
> 
> So to clearly describe the work you touch on here:
> 
> We have:
>  * global-requirements.txt:
>     origin/stable/liberty : oslo.concurrency>=2.3.0         # Apache-2.0
>  * upper-constraints.txt
>     origin/stable/liberty : oslo.concurrency===2.6.1
>  * compatible oslo.concurrency releases:
>     2.3.0, 2.4.0, 2.5.0, 2.6.0 and 2.6.1(patched)
> 
> So to be sure that all liberty consumers have a reasonably simple update we'd
> need to create:
>     2.3.1, 2.4.1 and 2.5.1
> releases of oslo.concurrency
> 
> To achieve this we'd need to create a 3 short lived feature branches in
> oslo.concurrency and (I'm guessing) some CI changes so we can merge/release
> these versions.
> 
> We'd also need to update global-requirements.txt to:
>     oslo.concurrency>=2.3.1,!=2.4.0,!=2.5.0,!=2.6.0
> 
> This update would be propagated to all projects:
> 
> Package      : oslo-concurrency [oslo-concurrency>=2.3.0] (used by 30 projects)
> Re-Release   : 5 projects
> Included in  : 17 projects
> Also affects : 8 projects
> 
> (The expanded list is at http://paste.openstack.org/show/582499/)
> 
> I haven't looked into the state of the libraries that need a re-release, but my
> guess is that they'll have knock on effects if we're going to do this properly.
> 
> There's a reason we call this kind of thing a tangled web of onions.
> 
> I suppose the most flexible solution would be to:
> 
> 1. Release the .1 versions
> 2. Leave global-requirements.txt
> 2. Add the patch to nova to with with/without the fix
> 3. Write appropriate words in the OSSN/OSSA
> 
> That gives deployers plenty of packages they can work with and public backports
> of the fixes.  Yes g-r would be sub-optimal but the only thing that needs the
> fix will function with any of the versions listed.

Thanks for the succint analysis, Tony, that gives a clear view of state
of affairs if we had to go with three short-lived .1 releases.  Probably
this thread needs to be referred to in the commit message.

> .... Time passes ....
> 
> So I checked and the cherry-picks to 2.[345].0 are trivial so I think
> I just talked myself around to taking the nova fix now we can decide
> if we do all the .1 releases later

So, given your above comment, we seem to be going with the "option (1)"
as mentioned in the original post[x] -- i.e.  merge the Nova backport.
 
Thanks for the review (and the test with 2.6.0)

[x] http://lists.openstack.org/pipermail/openstack-dev/2016-September/104091.html

-- 
/kashyap