OpenStack Developer Mailing List Digest March 26 – April 1

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

The Plan For the Final Week of the Mitaka Release

  • We are approaching the final week of Mitaka release cycle.
  • Important dates:
    • March 31st was the final day for requesting release candidates for projects following the milestone release model.
    • April 1st is the last day requesting full releases for service projects following the intermediary release model.
    • April 7th 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

[1] –

[2] –

[3] –

[4] –

[5] –

[6] –

[7] –

[8] –

[9] –

[10] –

[11] –

[12] –

[13] –

Leave a Reply

Your email address will not be published. Required fields are marked *