The content below is taken from the original (OpenStack Developer Mailing List Digest March 26 – April 1), to continue reading please visit the site. Remember to respect the Author & Copyright.

SuccessBot Says

Tonyb: Dims fixed the Routes 2.3 API break
pabelanger: migration from devstack-trusty to ubuntu-trusty complete!
Tell us yours via IRC with a message “#success [insert success]”.
All

Voting for the Technical Committee Election Is Now Open

We are selecting 7 TC members.
Confirmed candidates [1]
You are eligible to vote if you are a Foundation individual member [2] that also committed to one of the official projects [3] during the Liberty and Mitaka development.
Important dates:
- Election open: 2015-04-01 00:00 UTC
- Election close: 2015-04-07 23:59 UTC
More details on the election [4]
Full thread

Release Process Changes For Official Projects

The release team worked on automation for tagging and documenting [5] focusing on the projects with the release:managed tag.
Second phase is to expand to all projects.
The release team will be updating gerrit ACLs for projects to ensure they can handle releases and branching.
Instead of tagging releases and then recording them in the release repository, all official teams can use the release repo to request new releases.
If you’re not familiar with the release process, review the README file in the openstack/releases repo [6].
Full thread

Service Catalog TNG Work in Mitaka … Next Steps

Mitaka included fact finding
public / admin / internal url
- Notion of an internal url is used in many deployments because there is a belief it means there is no change for data transfer.
- Some deployments make these all the same and use the network to ensure that internal connections hit internal interfaces.
- Next steps:
  - We need a set of user stories built from what we currently have.
project_id optional in projects – good progress
- project_id is hard coded into many urls for projects without any useful reason.
- Nova demonstrated removing this in micro version 2.18.
- A patch [7] is up for devstack to enable this.
- Next steps:
  - Get other projects to remove project_id from their urls.
Service types authority
- We agreed we needed a place to recognize service types [8].
- The assumption that there might be a single URL which describes an API for a service is not an assumption we fulfill even for most services.
- This bump led to [9] some shifted effort on API reference to RST work.
- Next steps:
  - Finish API documentation conversion work.
  - Review patches for service type authority repo [10]
Service catalog TNG Schema
- We have some early work setting up a schema based on the known knowns, and leaving some holes for the known unknowns until we get a few of these locked down (types / allowed urls).
- Next steps:
  - Review current schema.
Weekly Meetings
- The team has been meeting weekly in #openstack-meeting-cp until release crunch and people got swamped.
- The meeting will be on hiatus for now until after Austin summit, and then start back up after the week of getting back.
Full thread

Oh Swagger, Where Art Thou?

Previously it has been communicated of the move from WADL to Swagger for API reference information.
It has been discovered that Swagger doesn’t match all of our current API designs.
There is a compute server reference documentation patch [11] using Sphinx, RST to do a near copy of the API reference page.
- There is consensus with Nova-API team, API working group and others to go forward with this.
We can still find uses for Swagger for some projects that match the specification really well.
Swagger for example doesn’t support

Showing the changes between micro
Projects that have /actions resource allow multiple differing request bodies.

A new plan is coming, but for now the API reference and WADL files will remain in the api-site repository.
There will be a specification and presentation in the upstream contributor’s track about Swagger as a standard [12].
Full thread

Cross-Project Summit Session Proposals Due

When: April 2^nd
Where: etherpad [13]
Full thread

The Plan For the Final Week of the Mitaka Release

We are approaching the final week of Mitaka release cycle.
Important dates:
- March 31^st was the final day for requesting release candidates for projects following the milestone release model.
- April 1^st is the last day requesting full releases for service projects following the intermediary release model.
- April 7^th the release team will tag the most recent release candidate for each milestone.
- The release team will reject or postpone requests for new library releases and new service release candidates by default.
- Only truly critical bug fixes which cannot be fixed post-release will be determined by the release team.
Full thread