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
Quelle: openstack.org
Published by