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
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
