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 protected].
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
- dhellmann:  is live with release history and upcoming release schedules.
- ttx: Governance changes are now announced in #openstack-dev, to increase general awareness about them!
- jklare: Just merged the first batch of opentack-chef cookbook patches for the Mitaka cycle! 4.229 lines of code refactored and 18.678 lines removed!
- johnthetubaguy: Nova subteams starting to look after themselves, and effectively reporting their progress to the wider community
- All: https://wiki.openstack.org/wiki/Successes
Dropping KEYSTONE_CATALOG_BACKEND – Plus Update Your Devstack Plugins
- Devstack has some half baked support for Keystone templated service catalog.
- In an effort to clean up parts of Devstack, we’re dropping that .
- This breaks everyone’s Devstack plugin that references the KEYSTONE_CATALOG_BACKEND variable.
- This variable will be kept around until Newton development opens up.
- Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-February/086272.html
All Hail the New Per-region PyPI, wheel and APT Mirrors
Release countdown for week R-7, Feb 15-19
- Focus: Project teams should be focusing on wrapping up new feature work in all libraries.
- Release Actions:
- We will be strictly enforcing the library release freeze before Mitaka-3 in 2 weeks.
- Review client libraries, integration libraries, and any other libraries managed by your team, and ensure recent changes have been released.
- Ensure global-requirements and constraints lists are up to date, with accurate minimum versions, and exclusions.
- Projects using cycle-with-intermediary release model need to produce intermediate releases. See Thierry’s emails for details .
- Review stable/liberty branches and submit patches to openstack/releases if you want them.
- Important Dates
- Final release for non-client libraries: Feb 24
- Final release for client libraries: Mar 2
- Mitaka 3: Feb 29-Mar 4 (includes feature freeze and soft string freeze)
- Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-February/086362.html
Why WADL When You Can Swagger
- Continuing from previous update .
- Every build of the api-site is now running fairy-slipper to migrate from WADL to Swagger.
- Those migrated Swagger files are copied to .
- Not all files migrate smoothly. We’d love to get teams looking at these migrated files. Thank you to those who have already submitted fixes!
- If you see a problem in the original WADL when viewing , log it .
- If you see a problem with the migration tool, log it .
- The Infra team is reviewing a specification  so that we can serve API information from developer.openstack.org.
- You can hop onto #openstack-doc or #openstack-sdks to ask nick annegentle
- Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-February/086467.html
Tenant VS. Project
- Sean Dague brings up that OpenStack’s use of tenant vs. project. Which are we transitioning to?
- Keystone is working towards allowing project_id in the service catalog .
- Neutron is transitioning to project_id now.
- The current Ansible OpenStack modules are using project .
- OSLO Logging/Context are using project.
- Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-February/086396.html
Proposal: Separate Design Summits From OpenStack Conferences
- The OpenStack design summits originally started out as working events.
- The OpenStack summits growing more marketing and sales focus, the contributors attending are often unfocused.
- Some contributors submit talks for the conference, because their company says it’s the only way for them to attend the conference. Part of the reason for this is the cost of attending.
- Thierry Carrez (who helps organize the design summit) explains that he has been working a solution for separation of the summit and the conference himself, and the Foundation is finalizing a strawman proposal that will be pushed to the community for comments soon.
- Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-February/086007.html
 – http://releases.openstack.org
 – https://review.openstack.org/#/c/278333
 – http://lists.openstack.org/pipermail/openstack-dev/2016-February/086152.html
 – http://www.openstack.org/blog/2016/01/openstack-developer-mailing-list-digest-january-9-15/
 – http://developer.openstack.org/draft/swagger
 – https://review.openstack.org/#/c/276484/
 – https://bugs.launchpad.net/openstack-api-site
 – https://bugs.launchpad.net/openstack-doc-tools
 – https://review.openstack.org/#/c/279576/
 – http://docs.ansible.com/ansible/list_of_cloud_modules.html#openstack
Upstream development track – please submit
We’ll have an “Upstream development” track at the Austin Summit. It will happen on the Monday, before the Design Summit starts. This is a classic Summit conference track with recorded videos, so we want polished proposals for this track. We expect these to include general communication about development process changes, new features in a central project that need adoption in other projects, corner use cases that may need support from development, developer-oriented infra talks and upstream development best practices. To propose a talk for this track, use the Summit proposal system, select Upstream development, and meet the February 1st deadline.
The OpenStack overall mission has stood proudly for years now, and is due for an update to increase focus on cloud consumers rather than solely on cloud builders. So we have proposed an amendment to the original mission. You can read the current and proposed new mission on governance.openstack.org.
And now, even more doc
In a clarification effort, we pushed the definition of the 4 opens, as well as clarified OpenStack licensing requirements as reference documents under the governance repository. Previously those were maintained in oral tradition, the wiki, or left as an exercise to the reader of the Foundation bylaws. You can now find them published (like all Technical Committee resolutions and reference information) on the governance website.
The names are here! The names are here!
The N and O releases directly after Mitaka will be Newton and Ocata. For the Austin Summit, the tie-in is to the “Newton House”, located at 1013 E. Ninth Street in Austin, Texas. It’s listed on the National Register of Historic Places. For the Barcelona Summit, know that Ocata is a beach about 20 minutes north of Barcelona by train.
Clarifying licensing requirements
A new governance page clarifies guidelines for licensing for projects in and around OpenStack. We want to raise awareness and highlight that page for future reference. In the subset of OpenStack projects that may be included in a Defcore trademark program, the project must be licensed under Apache Software License v2, ASLv2. Libraries and software built in the OpenStack infrastructure system should use OSI-approved licenses that do not restrict distribution of the consuming project. Read more on the governance website.