Open Stack

Perma Link: http://www.openstack.org/blog/2015/11/openstack-developer-mailing-list-digest-november-20151107/

New Management Tools and Processes for stable/liberty and Mitaka
====================================================

* For release management, we used a combination of launchpad milestone
pages and our wiki to track changes in releases.
* We used to pull releases notes for stable point releases at the time
of releases.
* Release managers would work with PTLs and release liaisons at each
milestone to update launchpad to reflect the work completed.
* All this requires a lot of work of the stable maintenance and release teams.
* To address this work with the ever-growing set of project, the
release team is introducing Reno for continuously building release
notes as files in-tree.

The idea is small YAML files, usually one per note or patch to avoid
merge conflicts on back ports, which are then compiled to a readable
document for readers.
ReStructuredText and Sphinx are supported for converting note files to
HTML for publication.
Documentation for using Reno is available [1].

* Release liaisons should create and merge a few patches for each
project between now and Mitaka-1 milestone:

  - To the master branch, instructions for publishing the notes. An
example of Glance [2].
  - Instructions for publishing in stable/liberty of the project. An
example with Glance [3].
  - Relevant jobs in project-config. An example with Glance [4].
  - Reno was not ready before the summit, so the wiki was used for
release notes for the initial Liberty releases. Liaisons should covert
those notes to Reno YAML files in stable/liberty branch.

* Use the topic ‘add-reno’ for all patches to track adoption.
* Once liaisons have done this work, launchpad can stop being used for
tracking completed work.
* Launchpad will still be used for tracking bug reports, for now.
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/078301.html


Keeping Juno “alive” For Longer
=========================

* Tony Breeds is seeking feedback on the idea of keeping Juno around a
little longer.
* According to the current user survey [5], Icehouse still has the
biggest install base in production clouds. Juno is second, which means
if we end of life (EOL) Juno this month, ~75% of production clouds
will be running a EOL’d release.
* The problems with doing this however:

  - CI capacity of running the necessary jobs of making sure stable
branches still work.
  - Lack of resources of people who care to make sure the stable
branch continues to work.
  - Juno is still tied with Python 2.6.
  - Security support is still needed.
  - Tempest is branchless, so it’s running stable compatible jobs.

* This is acknowledged as a common request. The common answer being
“push more resources in fixing existing stable branches and we might
consider it”.
* Matt Riedmann who works in the trenches of stable branches confirms
stable/juno is already a goner due to requirements capping issues. You
fix one issue to unwedge a project and with global-requirement syncs,
we end breaking 2 other projects. The cycle never ends.
* This same problem does not exist in stable/kilo, because we’ve done
a better job of isolating versions in global-requirements with
upper-constants.
* Sean Dague wonders what are the reasons that keep people from doing
upgrades to begin with. Tony is unable to give reasons since some are
internal to his companies offering.
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/078630.html


Oslo Libraries Dropping Python 2.6 compatibility
=====================================

* Davanum notes a patch to drop py26 oslo jobs [6].
* Jeremy Stanley notes that the infrastructure team plans to remove
CentOS 6.X job workers which includes all python 2.6 jobs when
stable/juno reaches EOL.
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079249.html


Making Stable Maintenance its own OpenStack Project Team
===============================================

* Thierry writes that when the Release Cycle Management team was
created, it just happen to contain release management, stable branch
management, and vulnerability management.

  - Security Team was created and spun out of the release team today.

* Proposal: spin out the stable branch maintenance as well.

  - Most of the stable team work used to be stable point release
management, but as of stable/liberty this is now done by the release
management team and triggered by the project-specific stable
maintenance teams, so there is no more overlap in tooling used there.
  - Stable team is now focused on stable branch policies [7], not patches.
  - Doug Hellmann leads the release team and does not have the history
Thierry had with stable branch policy.
  - Empowering the team to make its own decisions, visibility,
recognition in hopes to encourage more resources being dedicated to
it.

    -- Defining and enforcing stable branch policy.
    -- If team expands, it could own stable branch health/gate fixing.
The team could then make decisions on support timeframes.

  - Matthew Treinis disagrees that the team separation solves the
problem of getting more people to work on gate issues. Thierry has
evidence though that making a its own project will result in
additional resources. The other option is to kill stable branches, but
as we’ve seen from the Keeping Juno Alive thread, there’s still
interest in having them.
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/078901.html


[1] - http://docs.openstack.org/developer/reno/
[2] - https://review.openstack.org/241323
[3] - https://review.openstack.org/241322
[4] - https://review.openstack.org/241344
[5] - http://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf
[6] - https://review.openstack.org/244275
[7] - http://docs.openstack.org/project-team-guide/stable-branches.html