OpenStack Developer Mailing List Digest April 29 – May 5

giraffelife

POST /api-wg/news

Newly Published Guidelines
- Create a set of API interoperability guidelines 1
Guidelines Current Under Review
- Microversions: add next_min_version 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