OpenStack Developer Mailing List Digest January 16-22

The content below is taken from the original (OpenStack Developer Mailing List Digest January 16-22), to continue reading please visit the site. Remember to respect the Author & Copyright.

Success Bot Says

  • mriedem: nova liberty 12.0.1 released [1].
  • OpenStack Ansible Kilo 11.2.7 has been released.
  • OpenStack-Ansible Liberty 12.0.4 has been released.
  • Tell us yours via IRC with a message “#success [insert success]”.
  • All:


  • License requirement clarification for big tent projects [2].
  • Make constraints opt in at the test level [3].
  • OSprofiler is now an official OpenStack project [4].


  • TC approved:
    • Deprecate individual CLIs in favor of OpenStack client [5].
    • clouds.yaml support in clients [6].
  • Current open specs:

Release Count Down For Week R-10, Jan 25-29

  • Focus: with the second milestone behind us, project teams should be focusing on wrapping up new feature work and stabilizing recent additions.
  • Release actions:
    • Strictly enforcing library release freeze before M3 (5 weeks).
    • Review client/integration libraries and whatever other libraries managed by your team.
    • Ensure global requirements and constraints lists are up to date with accurate minimum versions and exclusions.
    • Quite a few projects with unreleased changes on stable/liberty branch. Check for your project [7].
  • Important dates:
    • Final release for non client libraries: February 24th
    • Final release for client libraries: March 2nd
    • Mitaka-3: Feb 29 through March 4 (includes feature freeze and soft string freeze).
    • Mitaka release schedule [8].
  • Full thread:

Stabilization Cycles: Elaborating on the Idea To Move It Forward

  • At the Tokyo summit, the OpenStack Development Theme session, in which people discuss overall focus in shared efforts, having cycles to stabilize projects was brought up.
  • A project could decide to spend some percentage of time of the cycle on focusing on bug fixing, review backlog, refactoring, instead of entirely on new features.
  • Projects are already empowered to do this, however, maybe the TC could work on formalizing this process so that teams have a reference when they want to.
  • Some contributors from the summit feel they need the Technical Committee to take leadership on this, so that they can sell it back to their companies.
  • Another side of discussion, healthy projects should naturally come up with bursts of feature additions and burst of repaying technical debt continuously.
    • Imposing specific periods of stabilization prevents reaching that ideal state.
  • Full thread: