Open Stack

HTML version: https://www.openstack.org/blog/2017/05/openstack-developer-mailing-list-digest-20170507/

POST /api-wg/news
=================
* Newly Published Guidelines
    * Create a set of API interoperability guidelines [1]
* Guidelines Current Under Review
    * Microversions: add nextminversion field in version body [2]
    * A suite of five documents about version discovery [3]
    * Support for historical service type aliases [4]
    * WIP: microversion architecture archival document [5]
* Full thread: [6]

Release countdown for week R-16 and R-15 May 8-9
================================================
* Focus:
    * Pike feature development and completion of release goals.
    * Team members attending the Forum at the Boston summit should be focused
      in requirements gathering and collecting feedback from other parts of the
      community.
* Actions:
    * Some projects still need to do Ocata stable point release.
        * aodh
        * barbican
        * congress
        * designate
        * freezer
        * glance
        * keystone
        * manila
        * mistral
        * sahara
        * searchlight
        * tricircle
        * trove
        * zaqar
    * Projects following intermediary-release models and haven’t done any:
        * aodh
        * bitfrost
        * ceilometer
        * cloud kitty[-dashboard]
        * ironic-python-agent
        * karbor[-dashboard]
        * magnum[-ui]
        * murano-agent
        * panko
        * senlin-dashboard
        * solum[-dashboard]
        * tacker[-dashboard]
        * virtage[-dashboard]
    * Independent projects that have not published anything for 2017:
        * solum
        * bandit
        * syntribos
    * Upcoming deadlines and dates:
        * Forum at OpenStack Summit in Boston: May 8-11
        * Pike-2 milestone 2: June 8
    * Full thread: [7]

OpenStack moving both too fast and too slow at the same time
============================================================
* Drew Fisher makes the observation that the user survey [8] shows the same
  issue time and time again on page 18-19.
    * Things move too fast
    * No LTS release
    * Upgrades are scary for anything that isn’t N-1 -> N
	* The OpenStack community has reasonable testing in place to ensure
	  that N-1 -> N upgrades work.
* Page 18: "Most large customers move slowly and thus are running older
  versions, which are EOL upstream sometimes before they even deploy them."
* We’re unlikely to add more stable releases or work on them longer because:
    * We need more people to do the work. It has been difficult to attract
      contributors to this area.
    * Find a way to do that work that doesn’t hurt our ability to work on
      master.
* We need older versions of the deployment platforms available in our CI to run
  automated tests.
    * Supported version of development tools setup tools and pip.
    * Supported versions of the various libraries and system-level dependencies
      like libvirt.
* OpenStack started with no stable branches, where we were producing releases
  and ensuring that updates vaguely worked with N-1 -> N.
* Distributions maintained their own stable branches.
    * It was suggested instead of doing duplicate effort, to share a stable
      branch.
        * The involvement of distribution packagers became more limited.
        * Today it’s just one person, who is currently seeking employment.
* Maintaining stable branches has a cost.
    * Complex to ensure that stable branches actually keep working.
    * Availability of infrastructure resources.
* OpenStack became more stable, so the demand for longer-term maintenance
  became stronger.
    * People expect upstream to provide it, not realizing that upstream is made
      of people employed by various organizations, and apparently this isn’t of
      interest to fund.
* Current stable branch model is kind of useless in only supporting stable
  branches for one year. Two potential outcomes:
    * The OpenStack community still thinks there is a lot of value in doing
      this work upstream, in which organizations should invest resources in
      making that happen.
    * The OpenStack community thinks this is better handled downstream, and we
      should get rid of them completely.
* For people attending the summit, there will be an on-boarding session for the
  stable team [9]
* Matt Riedemann did a video [10] ether pad [11] and slides [12] on the stable
  work.  In the end, it was determined the cost of doing it didn’t justify the
  dream on, lack of resources to do it.
* Full thread: 13


[1] - https://review.openstack.org/#/c/421846/
[2] - https://review.openstack.org/#/c/446138/
[3] - https://review.openstack.org/#/c/459405/
[4] - https://review.openstack.org/#/c/460654/3
[5] - https://review.openstack.org/444892
[6]  - http://lists.openstack.org/pipermail/openstack-dev/2017-May/116374.html
[7] - http://lists.openstack.org/pipermail/openstack-dev/2017-May/116401.html
[8] - https://www.openstack.org/assets/survey/April2017SurveyReport.pdf
[9] - https://www.openstack.org/summit/boston-2017/summit-schedule/events/18694/infraqarelease-mgmtregsstable-project-onboarding
[10] - https://www.openstack.org/videos/video/openstack-stable-what-it-actually-means-to-maintain-stable-branches
[11] - https://etherpad.openstack.org/p/stable-branch-eol-policy-newton
[12] - https://docs.google.com/presentation/d/1k0mCHwRZ3_Z8zJw_WilsuTYYqnUDlY2PkgVJLz_xVQc/edit?usp=sharing
[13] - http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116298


-- 
Mike Perez
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170507/783127e4/attachment.sig>