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)
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
