- 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]”.
Voting for the Technical Committee Election Is Now Open
- We are selecting 7 TC members.
- Confirmed candidates 
- You are eligible to vote if you are a Foundation individual member  that also committed to one of the official projects  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 
- Full thread
Release Process Changes For Official Projects
- The release team worked on automation for tagging and documenting  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 .
- 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  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 .
- 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  some shifted effort on API reference to RST work.
- Next steps:
- Finish API documentation conversion work.
- Review patches for service type authority repo 
- 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:
- 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  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 .
- 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
 – https://wiki.openstack.org/wiki/TC_Elections_April_2016#Confirmed_Candidates
 – http://www.openstack.org/community/members/
 – http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
 – https://wiki.openstack.org/wiki/TC_Elections_April_2016
 – http://specs.openstack.org/openstack-infra/infra-specs/specs/centralize-release-tagging.html
 – http://git.openstack.org/cgit/openstack/releases/tree/README.rst
 – https://review.openstack.org/#/c/233079/
 – http://lists.openstack.org/pipermail/openstack-dev/2016-February/thread.html#85748
 – http://lists.openstack.org/pipermail/openstack-dev/2016-March/090659.html
 – https://review.openstack.org/#/q/project:openstack/service-types-authority
 – https://review.openstack.org/#/c/292420
 – https://www.openstack.org/summit/austin-2016/summit-schedule/events/7723
 – https://etherpad.openstack.org/p/newton-cross-project-sessions
Long time, no see!
Poppy and our Open Core discussion
The Poppy team applied to add the project under OpenStack governance. Poppy, for those of you not familiar with it, provides CDN as a service. It’s a provisioning service – like other projects in OpenStack, such as Nova – but for CDNs. The overall proposal seemed to be fine except for one thing, there are no open source solutions for CDNs. This means Poppy provisions CDNs based on other commercial services and it requires consumers of Poppy to have an account in one of those CDN services to be able to use it.This presents several issues from an OpenStack perspective. One of them is the one mentioned before, which is that using Poppy requires clouds to rely on other CDNs. Another issue is that there is not good way to test the service in OpenStacks gates as there’s no open source solution for it. The OpenStack infra team won’t be subscribing to any of those CDN services for testing Poppy and nor is the Poppy team either.
There were quite a few discussions on this topic and the TC voted on whether the open core “issue” was critical enough to allow or reject Poppy from the big tent. In the review, there are different points of views on whether Poppy is actually Open Core or not and whether it should be allowed into OpenStack’s big tent regardless of the lack of an open source CDN solution. Ultimately the TC decided to reject the Poppy proposal in a close vote, 7-6.
Mission statement, take 2
As Russell Bryant puts it well in this Foundation mailing list thread, the OpenStack mission statement has held up pretty well for the life of the project. Discussions started about updates to ensure we include some key themes as focus areas for our growing community: interoperability and end users needs. The OpenStack technical committee has created an iteration on the mission statement, and the board is discussing as well. Take a look at the revisions so that our modifications can get buy-in across the community.
The OpenStack big tent welcomes the following official project teams:
- Dragonflow, a distributed control plane implementation of Neutron that implements advanced networking services driven by the OpenStack Networking API.
- Kuryr, a bridge between container framework networking models and the OpenStack networking abstraction.
- Tacker, a lifecycle management tool providing Network Function Virtualization (NFV) Orchestration services and libraries.
- EC2API, provides an EC2-compatible API for accessing OpenStack features.
New tag: stable:follows-policy
This new tag allows for indicating which deliverables follow the stable policy. The existing `release:has-stable-branches` tag that had been used so far ended up only describing if a deliverable has a branch called “stable/something”, and therefore did not properly indicate that stable policies are being followed. The new tag aims to cover that area and should eventually completely supersede the existing tag. You can read more about this tag in the tag reference page.
This blog post was co-authored by Flavio Percoco and Thierry Carrez.
We’re looking for a new design to grace OpenStack’s T-Shirts in 2016. Here’s your chance to show us your creative talent and submit an original design for our 2016 OpenStack T-shirt Design Contest!
If you’d like to participate simply send a sketch of your design to email@example.com.
Deadline: March 11, 2016
The winning design will be showcased on T-Shirts given out at an upcoming OpenStack event as well as on the new OpenStack online store!
(Click image to view deadline restrictions)
For some inspiration, check out last year’s winning design by Joline Buscemi. Get your pencils sharpened or fire up your design software of choice and send us your sketches! We’re excited to see what you’ll come up with!
2015 Winning T-Shirt Design
- The design must be your own original, unpublished work and must not include any third-party logos or copyrighted material; by entering the competition, you agree that your submission is your own work
- Design should be one that appeals to the majority of the OpenStack developer community
- Design may include line art, text, and photographs
- Your design is for the front of the shirt and may encompass an area up to 10″ x 10″ (inches)
- Design may use a maximum of three colors
The Fine Print:
- One entry per person, please. And it must be original art. Content found on the internet rarely has the resolution needed for print, and it’s considered unlawful to use without permission.
- Submissions will be screened for merit and feasibility, and we reserve the right to make changes such is image size, ink or t-shirt color before printing.
- By submitting your design, you grant permission for your design to be used by the OpenStack Foundation including, but not limited to, the OpenStack website, the OpenStack online store, and future marketing materials.
- The OpenStack Foundation reserves the right to final decision.
- The creator of the winning design will receive attribution on the T-shirt and public recognition on the OpenStack website!
- Takeaways from the OpenStack Mid-Cycle Ops Meetup: first time’s the charm 
- OpenStack Upgrading Tutorial: 11 pitfalls and solutions 
“No Open Core” in 2016 (continuing)
- Continuing with discussions on Poppy in particular, Doug Hellmann raises that the Poppy team has done everything we’ve asked. The governance currently emphasizes on the social aspects of the project and community interactions. Tell the Poppy team they “are not OpenStack” even though they followed things is distressing.
- Sean Dague mentions that solutions like Neutron have an open source solution. It may needed some work, but at least there was one open source solution for testing.
- Dean Troyer brings up how we have things like Cinder with commerical products as storage drivers. Even without those storage drivers though, Cinder is still useful.
- Poppy’s open source implementation option, OpenCDN is currently an abandoned project.
- Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-February/085855.html
Upgrade Implications of Lots of Content in paste.ini
- A set of Cross-origin resource sharing (CORS) patches came out recently , that adds a ton of content to paste.ini.
- Paste.ini is a config that operators can change.
- Large amounts of complicated things in there which may change in future releases is really problematic.
- Deprecating content also is a challenge.
- Why aren’t these options just the defaults of the CORS middlware?
- Some projects like Ironic did request to not have headers prescribed, for eample, if Ironic is using something other than Keystone, different allowed headers would be required.
- However, Keystone is defcore, so the default should be useful there first. Then be flexible to other auth options can go on top.
- Where do we go from here?
- Option 1: Implement as is, keep things consistent, fix them in Newton.
- This is not fixable in Newton as it requires deprecating out for the next three releases.
- Option 2: Try to fix it in Mitaka 2 of CORS middleware setting defaults and projects having the ability to override .
- This will require patches against a bunch of projects . Who can help?
- Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-February/086746.html
 – http://superuser.openstack.org/articles/takeaways-from-the-openstack-mid-cycle-ops-meetup-first-time-s-the-charm
 – http://superuser.openstack.org/articles/openstack-upgrading-tutorial-11-pitfalls-and-solutions
 – https://review.openstack.org/#/c/265415/1
 – http://docs.openstack.org/developer/oslo.config/generator.html#modifying-defaults-from-other-namespaces
 – http://governance.openstack.org/reference/projects/index.html