Open Stack

Hi!

We had a double session on extended maintenance at the Forum in 
Vancouver, here is a late summary of it. Feel free to add to it if you 
remember extra things.

The first part of the session was to present the Extended Maintenance 
process as implemented after the discussion at the PTG in Dublin, and 
answer questions around it.

The process was generally well received, with question on how to sign up 
(no real sign up required, just start helping and join 
#openstack-stable). There were also a number of questions around the 
need to maintain all releases up to an old maintained release, with 
explanation of the FFU process and the need to avoid regressions from 
release to release.

The second part of the session was taking a step back and discuss 
extended maintenance in the context of release cycles and upgrade pain. 
A summary of the Dublin discussion was given. Some questions were raised 
on the need for fast-forward upgrades (vs. skip-level upgrades), as well 
as a bit of a brainstorm around how to encourage people to gather around 
popular EM releases (a wiki page was considered a good trade-off).

The EM process mandates that no releases would be tagged after the end 
of the 18-month official "maintenance" period. There was a standing 
question on the need to still release libraries (since tests of HEAD 
changes are by default run against released versions of libraries). The 
consensus in the room was that when extended maintenance starts, we 
should switch to testing stable/$foo HEAD changes against stable/$foo 
HEAD of libraries. This should be first done when Ocata switches to 
extended maintenance in August.

The discussion then switched to how to further ease upgrade pain, with 
reports of progress on the Upgrades SIG on better documenting the Fast 
Forward Upgrade process. We discussed how minimal cold upgrades 
capabilities should be considered the minimum to be considered an 
official OpenStack component, and whether we could use the Goals 
mechanism to push it. We also discussed testing database migrations with 
real production data (what turbo-hipster did) and the challenges to 
share deidentified data to that purpose.

Cheers,

-- 
Thierry Carrez (ttx)