OpenStack Developer Mailing List Digest Feb 27 – March 4

SuccessBot Says

  • ttx: Mitaka-3 is done.
  • Odyssey4me: OpenStack-Ansible Liberty 12.0.7 is released [1].
  • johnthetubaguy: Nova is down to four pending blueprints for feature freeze now [2], sort of one day left. Better than it was this morning at least.
  • Russellb: Got a set of OVS flows working in OVN that applies security group changes immediately to existing connections.
  • Tell us yours via IRC with a message “#success [insert success]”.
  • All

Cross-Project

  • Quotas and Nested Quotas Working group

Outreachy May-Aug 2016: Call For Funding and Mentors

  • Outreachy [5] helps people from groups underrepresented in free and open source software get involved by matching interns with established mentors in the upstream community.
  • We have 10 volunteer mentors for OpenStack this next cycle (May 23-August 23 2016).
    • Learn more and apply to be a mentor [6]
  • Potential sponsors have reached out, but we need more due to the increase in applicants.
    • Each intern is $6,500 for the three-month program.
    • The OpenStack Foundation has confirmed participation.
    • Learn more and apply to be a sponsor [7].
  • Regardless, help spread the world!
  • Full thread

Changing Microversion Headers

  • The API working group would like to change the format of headers used for microversions to make them more future proof before too many projects are using them.
    • Proposed guideline [8].
  • This came up in another guide for header non-proliferation [9].
  • After plenty of discussions, and with projects already deploying microversions (Nova, Ironic, Manila) the proposal is change basic from:
    • X-OpenStack-Nova-API-Version: 2.11
    • OpenStack-Compute-API-Version: 2.11
  • To:
    • OpenStack-API-Version: compute 2.11
  • This allows us to use one header name for multipel services and avoids some of the problems described in the header non-proliferation guideline [9].
  • Full thread

OpenStack Contributor Awards

  • The Foundation would like introduce some informal quirky awards to recognize the extremely valuable work that we all do to make Openstack excel.
  • With many different areas to celebrate, there are a few main chunks of the community that need a little love:
    • Those who might not be aware that they are valued, particularly new contributors
    • Those who are the active glue that binds the community together
    • Those who share their hard-earned knowledge with others and mentor
    • Those who challenge assumptions, and make us think
  • Nominate someone who you think is deserving of an awards [10]!
  • Full thread

Status Of Python 3 In OpenStack Mitaka

  • 13 services were ported to Python 3 during the Mitaka cycle: Cinder, Glance, Heat, Horizon, etc.
  • 9 services still need to be ported
  • Next Milestone: Functional and integration tests
  • “Ported to Python 3” means that all unit tests pass on Python 3.4 which is verified by a voting gate job. It is not enough to run applications in production with Python 3. Integration and functional tests are not run on Python 3 yet.
  • Read the full status post [11] by Victor Stinner.
  • Join Freenode channel #openstack-python3 to discuss and help out!
  • Full thread

 

2016 OpenStack T-Shirt Design Contest

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!

shirt-contest-promo3

(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

2015 contest-shirt

 

Guidelines:

  • 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!

 

 

 

 

 

OpenStack Developer Mailing List Digest Feb 20-26

Audience for Release Notes

  • We have 3 potential audiences for release notes:
    • Developers consuming libraries or other code directly.
    • Deployers and operators.
    • End-users.
  • Two kinds of documentation being discussed:
    • Reno [1] for release notes [2]
      • Keep in mind the audience is *not* someone who is necessarily going to be looking at code or writing apps based on libraries we produce..
      • Highlight information that deployers and operators will need, like changes to configuration options or service behaviors.
      • Describe REST API changes that an end-user may need to know about.
    • In-tree developer documentation [3] for Developers.
      • Internal details, library API changes, etc. — any changes the deployer is not going to see.
  • The two sets of documentation are meant for different purposes, so we need to think about what information we publish in each.
  • Full thread [4]

A Proposal to Separate the Design Summit

Today

  • Since the beginning, we’ve had face to face time at Design Summits to discuss development cycles to set goals and organize the work for the upcoming 6 months.
  • A more traditional conference took place at the same time to ensure interaction between upstream and downstream parts of our community.

Current Issues

  • For developers:
    • Difficult to focus on upstream work with so many distractions coming from the conference.
    • As a result the summit is less productive, and we form midcycles to fill our focus.
  • For companies:
    • Flying all their developers to expensive cities and conference hotels for the summit is pretty costly. – The goals of the summit location reaching out to users everywhere does not necessarily align with the goals of the design summit location.
    • Not enough time to build products on top of the recent release.
  • Not enough time for users to try out the new release to have feedback.
  • Finding venues that can accommodate both events is becoming increasingly complicated.

How to Split up the events

  • The first event would be for upstream technical contributors of OpenStack.
    • Held in a simpler, scaled-back setting that would let all OpenStack project teams meet in separate rooms, but in a co-located event that would make it easy to have ad-hoc cross-project discussions.
    • It would be held in closer to the centers of mass of contributors, in less-expensive locations.
    • It would happen a couple of weeks /before/ the previous cycle release. There is a lot of overlap between cycles. Work on a cycle starts at the previous cycle feature freeze, while there is still 5 weeks to go. Most people switch full-time to the next cycle by RC1. Organizing the event just after that time lets us organize the work and kickstart the new cycle at the best moment. It also allows us to use our time together to quickly address last-minute release-critical issues if such issues arise.
  • The second event would be the main downstream business conference.
    • This includes high-end keynotes, marketplace, and break out sessions.
    • Organized two or three months /after/ the release, to give time downstream users to deploy and build products on top of the release.
    • This will better allow us to gather feedback on the recent release, a gather requirements for the next cycle.
    • A subset of contributors who would like to participate in sessions can collect and relay feedback to other team members (similar to the operators midcycle meetups).
  • The split should reduce the number of midcycle events, however, if they’re still needed, they could happen at the conference event (which is in the middle of the cycle).
  • The split means that we need to stagger the events and cycles. We have a long time between Barcelona and the Q1 Summit in the US, so the idea would be to use that long period to insert a smaller cycle (Ocata) with a release early March, 2017 and have the first specific contributors event at the start of the P cycle, mid-February, 2017. With the already-planned events in 2016 and 2017 it is the earliest we can make the transition. We’d have a last, scaled-down design summit in Barcelona to plan the shorter cycle.
  • Operators midcycle will still continue to happen.
summit-split

Voiced Concerns and Answers:

  • This creates two events instead of one. Creates community split, with developers skipping the main and non-developers not providing any feedback to the contributor specific event.
    • There will still be a lot of strategic discussions at the main event.
    • This is where we look at the N-1 release and start drawing plans and cross-project themes for the N+1 release.
    • We don’t need every developer there, but we still need a significant chunk of them, with every team represented, so that we can have those strategic and cross-project discussions.
    • Someone who wants to keep touch with development could still make only one trip, so it’s not expected for the communities to be split. We’d still all be represented in the main event.
  • Losing the main summit as an excuse to fund developers’ travel. Some developers are only sent to the Design summit because the main event is happening at the same time.
    • If you have to pretend to attend the Summit to be able to attend the Design Summit instead, there is deception involved. You should a talk with your employer on where the most value lies for you in attending which event.
    • The Foundation also has the Travel support program to cover the gaps [5].
  • The fear of US-centricity (translating from “closer to the centers of mass of contributors”). This makes travel cost cheaper at the expense of making it more costly for non-US parts of our community.
    • The goal is “minimize and *balance* travel costs for existing contributors”. There will still be some continent rotation involved, but we need to balance cost and fair.
  • The lost of midcycle spirit. Some people really like the midcycles as they stand: separated small events where only your small team is around. The split appears to reduce the likelihood, the need, or the funding for such events.
    • While the hope is the proposed format will let us fulfill all our team socialization needs, it’s true that there will be other people around, and it will feel a lot less exclusive and special.
    • The trade-off is that having people all together encourages cross-project work and breaks silos.
  • Full thread [6]

OpenStack Developer Mailing List Digest Feb 13-19

OpenStack Operators

  • Takeaways from the OpenStack Mid-Cycle Ops Meetup: first time’s the charm [1]
  • OpenStack Upgrading Tutorial: 11 pitfalls and solutions [2]

“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 [3], 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 [4].
      • This will require patches against a bunch of projects [5]. Who can help?
  • Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-February/086746.html

 

[1] – http://superuser.openstack.org/articles/takeaways-from-the-openstack-mid-cycle-ops-meetup-first-time-s-the-charm

[2] – http://superuser.openstack.org/articles/openstack-upgrading-tutorial-11-pitfalls-and-solutions

[3] – https://review.openstack.org/#/c/265415/1

[4] – http://docs.openstack.org/developer/oslo.config/generator.html#modifying-defaults-from-other-namespaces

[5] – http://governance.openstack.org/reference/projects/index.html

OpenStack Developer Mailing List Digest Feb 7-12

SuccessBot Says

  • dhellmann: [1] 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 [2].
  • 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 [3].
    • 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 [4].
  • Every build of the api-site is now running fairy-slipper to migrate from WADL to Swagger.
    • Those migrated Swagger files are copied to [5].
  • 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 [5], log it [7].
    • If you see a problem with the migration tool, log it [8].
  • The Infra team is reviewing a specification [6] 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 [9].
  • Neutron is transitioning to project_id now.
  • The current Ansible OpenStack modules are using project [10].
  • 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

[1] – http://releases.openstack.org
[2] – https://review.openstack.org/#/c/278333
[3] – http://lists.openstack.org/pipermail/openstack-dev/2016-February/086152.html
[4] – http://www.openstack.org/blog/2016/01/openstack-developer-mailing-list-digest-january-9-15/
[5] – http://developer.openstack.org/draft/swagger
[6] – https://review.openstack.org/#/c/276484/
[7] – https://bugs.launchpad.net/openstack-api-site
[8] – https://bugs.launchpad.net/openstack-doc-tools
[9] – https://review.openstack.org/#/c/279576/
[10] – http://docs.ansible.com/ansible/list_of_cloud_modules.html#openstack

OpenStack Developer Mailing List Digest Jan 23 – Feb 5

SuccessBot Says

  • odyssey4me: OpenStack Ansible Liberty 12.0.5 released.
  • stevemar: Devstack now defaults to v3 for Keystone.
  • boris-42: osprofiler functional job passed [1].
  • odyssey4me: OpenStack Ansible Kilo 11.2.9 released [2].
  • odyssey4me: OpenStack Ansible Liberty 12.0.6 released [3].
  • All: https://wiki.openstack.org/wiki/Successes

Cross-Project Specs

  • A common policy scenario across all projects [4].
  • Query config from web UI [5]

API Guidelines

  • Must not return service-side tracebacks [6].

Service Type vs. Project Name For Use In Headers

  • There’s a question of whether we should be using service type or project names in headers. Some reviews involving this [7][8][9][10].
  • We should be selecting things that better serve the API consumers and according to Dean Troyer the API working group is going in the right direction.
  • The service type as the primary identifier for endpoints and API services is well established, and is how the service catalog has and will always work. Service types therefore should be the way to go.
  • Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-January/085145.html

OpenStack Ansible Without Containers

  • Gyorgy annouces a new installer for OpenStack under GPLv3 using Ansible, but without containers.
    • Reasons for another installer since we already have the OpenStack Ansible project and Kolla:
      • Containers adding unnecessary complexity.
      • Packages: avoid mixing pip and distributor packages. Distributor packages includes things like init scripts, proper system users, upgrade possibilities, etc.
        • Kevin Carter mentions that these benefits are actually also included with the OpenStack Ansible project.
  • Without containers, upgrading a single controller can be tricky and disruptive since you have to upgrade every service at the same time. Rollbacks are also easier.
  • OpenStack Ansible project can already today do deployment without containers using the is_metal=true variable.
  • Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-January/084963.html

Release Countdown for Week R-8, Feb 8-12

  • Focus:
    • 2 more weeks before final releases for non-client libraries for this cycle.
    • 3 more weeks before the final releases for client libraries.
    • Projects should focus on wrapping up feature work in all libraries.
  • Release Actions:
    • The release team will be strictly enforcing library release freeze before M3 in 3 weeks.
  • 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/085705.html

“No Open Core” in 2016

  • Before OpenStack had a name, the “four opens” principles were created to define how we operate as a community.
  • In 2010 when OpenStack started, it was different from other open source cloud platforms (Eucalyptus) which followed open core strategy of producing a crippled community edition and an “enterprise version”.
  • Today we have a non-profit independent foundation, which cannot do an “enterprise edition”.
    • Today member companies build “enterprise products” on top of the apache licensed upstream project. Some are drivers that expose functionality in proprietary components.
  • What does it mean to “not do open core” in 2016? What is acceptable and what’s not?
  • Thierry Carrez believes it’s time to refresh this of what is an acceptable official project in OpenStack.
    • It should have a fully-functional production grade open source implementation
    • If you need proprietary software of commercial entity to fully use the project, then it should not be accepted in OpenStack as an official project.
      • These projects can still be non-official projects and still be hosted by OpenStack infrastructure.
  • Doug Hellmann brings up Poppy [11] which is applying to be an official OpenStack project.
    • A wrapper to content delivery networks, but there is no open source solution.
    • Is this something that can be an official project, or is open core?
  • Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-February/085855.html

The Trouble with Names

  • A few issues have crept up recently with the service catalog, API headers, API end points, and even similarly named resources in different resources (e.g. backup), that are all circling around a key problem. Distributed teams and naming collision.
  • Each project has a unique name that is ensured by their git repository in the OpenStack namespace.
  • There’s a desire to replace project names with generic names like nova/compute in:
    • service catalog
    • api headers
  • Options we have are:
    • Use the code names we already have: nova, glance, swift, etc.
      • Upside: collision problem solved.
      • Downside: You need a secret decoder ring to know what a project does.
    • Have a registry of common names.
      • Upside: we can safely use common names everywhere and not fear collision down the road.
      • Downside: yet another contention point.
  • Approvals by the various people in the community to have a registry of the common names. Maybe in the governance projects.yaml file [12]?
    • This list does include only the official projects by the technical committee, therefore only those projects can reserve the common names.
  • OpenStack Client has already encoded some of these common names to projects [13].
  • Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-February/085748.html

Announcing Ekko – Scalable Block-Based Backup for OpenStack

  • The goal of Ekko is to provide incremental block-level backup and restore of Nova instances.
  • Two place with overlapping goals:
    • Cinder volume without having the incremental backups be dependent.
    • Nova instances
      • OpenStack Freezer today leverages Nova’s snapshot feature.
      • Ekko would leverage live incremental block-level backup of a nova instance.
  • Jay Pipes begins the discussion on the two projects (Freezer and Ekko) working together to make sure their REST API endpoints are not overlapping. Having two APIs for performing backups that are virtually identical is not good.
  • The creator of Ekko sees the reason for another backup project because of “actual implementation and end results are wildly different” even if they are the same API call.
  • Jay doesn’t like that today all the following endpoints exist:
    • Freezer’s /backups
    • Cinder’s /{tenant_id}/backups
  • Having these endpoints make for bad user experience and is just confusing.
  • The current governance model does not prevent competition of projects. So if two projects overlap in API endpoints, there should be an attempt in collaboration.
  • Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-January/084739.html

Technical Committee Highlights January 22, 2016

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.

Our mission

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.

Newton House (Austin,TX)

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.

 

OpenStack Developer Mailing List Digest January 16-22

Success Bot Says

  • mriedem: nova liberty 12.0.1 released [1].
  • OpenStack Ansible Kilo 11.2.7 has been released.
  • OpenStack-Ansible Liberty 12.0.4 has been released.
  • Tell us yours via IRC with a message “#success [insert success]”.
  • All: https://wiki.openstack.org/wiki/Successes

Governance

  • License requirement clarification for big tent projects [2].
  • Make constraints opt in at the test level [3].
  • OSprofiler is now an official OpenStack project [4].

Cross-Project

Release Count Down For Week R-10, Jan 25-29

  • Focus: with the second milestone behind us, project teams should be focusing on wrapping up new feature work and stabilizing recent additions.
  • Release actions:
    • Strictly enforcing library release freeze before M3 (5 weeks).
    • Review client/integration libraries and whatever other libraries managed by your team.
    • Ensure global requirements and constraints lists are up to date with accurate minimum versions and exclusions.
    • Quite a few projects with unreleased changes on stable/liberty branch. Check for your project [7].
  • Important dates:
    • Final release for non client libraries: February 24th
    • Final release for client libraries: March 2nd
    • Mitaka-3: Feb 29 through March 4 (includes feature freeze and soft string freeze).
    • Mitaka release schedule [8].
  • Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-January/084678.html

Stabilization Cycles: Elaborating on the Idea To Move It Forward

  • At the Tokyo summit, the OpenStack Development Theme session, in which people discuss overall focus in shared efforts, having cycles to stabilize projects was brought up.
  • A project could decide to spend some percentage of time of the cycle on focusing on bug fixing, review backlog, refactoring, instead of entirely on new features.
  • Projects are already empowered to do this, however, maybe the TC could work on formalizing this process so that teams have a reference when they want to.
  • Some contributors from the summit feel they need the Technical Committee to take leadership on this, so that they can sell it back to their companies.
  • Another side of discussion, healthy projects should naturally come up with bursts of feature additions and burst of repaying technical debt continuously.
    • Imposing specific periods of stabilization prevents reaching that ideal state.
  • Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-January/084564.html

OpenStack Developer Mailing List Digest January 9-15

Success Bot Says

  • stevemar: Latest python-neutronclient use keystoneauth, yay!
  • devkulkarni: Devstack plugin for Solum finally working as expected.
  • dulek: Initial tests show that our rolling upgrades stuff is working fine – I’m able to use Mitaka’s Cinder API service with Liberty’s cinder-scheduler and c-volume services.
  • Tell us yours via IRC with a message “#success [insert success]”.

Cross-Project Specs & API Guidelines

  • Add clouds.yaml support specification [1]
  • Deprecate individual CLIs in favor of OSC [2]
  • Add description of pagination parameters [3].

Release Models To Be Frozen Around Mitaka-2

  • Deadline: Mitaka-2, January 21st
  • Example, your release model is release:independent, and you want to switch to cycle-oriented models (e.g. release:cycle-with-intermediary or release:cycle-with-milestones). [4]
  • To change your project, propose an openstack/governance change in reference/projects.yaml file [5].

Vision and Changes For OpenStack API Guides

  • New tool: fairy-slipper [6]
    • Migrate files from WADL to Swagger.
    • Serve up reference info.
  • New build jobs to build API guides from project repos to developer.openstack.org
  • It was discussed in the last cross-project meeting [7] to answer questions.
  • There are a variety of specs [8][9] to go over this work.
  • See what’s happening this month [10].

“Upstream Development” Track At the Austin OpenStack Summit

  • Call for speakers [11] at the OpenStack conference in Austin will have a new track targeted towards upstream OpenStack developers.
    • Learn about new development processes
    • Tools that the infrastructure team gives us
    • New OSLO library features (or elsewhere)
    • Best practices
  • Probably Monday before the design summit tracks start.
  • Have a topic that fits this audience? Submit it! [12]

You Almost Never Need to Change Every Repository

  • There have been a lot of patches that tweak the same thing across many, many repositories.
  • Standardizations are great, but if you’re making the same change to more than a few repositories, we should be looking at another way to have that change applied.
  • If you find yourself making the same change over and over in a lot of projects, start a conversation on the dev mailing list first.

Release Countdown For Week R-11, Jan 18-22

  • Focus:
    • Next week is the second milestone for the Mitaka cycle.
    • Major feature work should be making good process, or be re-evaluated to see it really needs to land this cycle.
  • Release Actions:
    • Liaisons should submit tag requests to the openstack/releases repository for projects following the cycle-with-milestone before the end of the day on Jan 21.
    • Release liaison responsibility update should be reviewed [13].
  • Important Dates:
    • Mitaka 2: January 19-21
    • Deadline for Mitaka 2 tag: Jan 21
    • Release models to be frozen: Jan 21

What’s next for application developer guides?

Summary

This month, the developer.openstack.org site gets a new look and changes its source tooling. Read on for details about how these changes affect your project team.

Why are we changing the developer.openstack.org site?

You might know that the developer.openstack.org site documents over 900GET/PUT/POST/DELETE/PATCH calls for a dozen OpenStack services already on the developer.openstack.org site. As a couple of the keynote speakers in Tokyo so elegantly put it, the trustworthiness and consistency of the OpenStack APIs influenced their decision to run their business workloads in an OpenStack cloud.

Those interfaces need docs, lots of docs, and not only reference docs. While it takes a huge effort to maintain accurate references, we also need to document API usage and scenarios.

Now that we’ve written both an API Guide and a “Writing your first OpenStack application” tutorial, we want the site to be the go-to location for app devs, product developers, and anyone who needs to unlock the power of their OpenStack infrastructure.

In this release, the docs’ platform introduces tooling that lets you migrate from WADL to Swagger and integrate RST-sourced documentation with the API reference documentation. The “why” analysis is clear: we must community-source this info and make it easy to maintain and update so that users can trust it enough to bet their workloads on it.

Later on, this post answers the “how” questions.

Why all these changes at this point in the release?

Well, we haven’t had to release the API documentation like we release services documentation. We have done a lot of maintenance on the site, with bug fixing and so on. But it’s time to take the leap. Last release we made a proof-of-concept. This release we unleash a solution that helps us make incremental progress toward our goals.

How do you keep your API docs updated after January 16th?

On January 16th, we’ll migrate the Images API WADL and DocBook files to Swagger and RST files. Then we’ll test the build process and the content itself to validate the migration.

After testing, we will migrate the files for these services:

  • Identity
  • Compute
  • Images
  • Networks
  • Block Storage
  • Object Storage

Then, the remaining services can migrate their files by using the validated tooling.

If you do provide an OpenStack API service, read on.

For the nova project, place your how-to and conceptual articles in the api-guide folder in the nova repository. Other projects can mimic these patches that created an api-guide and build jobs for the Compute api-guide. You continue to update reference information in the openstack/api-site repo. However, the source files have changed.

With this release, you can embed annotations in your source code if you want to generate the reference information. Here’s an example patch from the nova project. Because we haven’t had a project do this yet completely, the build jobs still need to be written.

If your project already has WADL files, they will be migrated to Swagger files and stored in the api-site repository. The WADL files will be deleted; you can retrieve them from Git.

If your project does not have a WADL file, then you write Swagger plus RST to document your API calls, parameters, and reference information. You can generate Swagger from annotations or create Swagger from scratch that you store in the api-site repository. You should review, store, and build RST for conceptual or how-to information from within your project team’s repository.

All projects should use this set of API documentation guidelines from the OpenStack API working group any time their service has a REST API. This document tells you what and how much to write. If you follow the suggested outline, your API guide will be accurate and complete.

After the source files and build jobs exist, the docs are built to developer.openstack.org.

Where can I get help for my project’s API Guides?

These specifications describe the details: Application Developer Guides and Rework API Reference Information.

You can ask questions in #openstack-sdks or #openstack-docs on IRC. We await those magical API docs fairies who grant wishes, but in the meantime but we can point you in the right direction and give you the tools for your quest.

What if I still have questions?

Contact me, Anne Gentle, by email or IRC and I’ll get back to you as soon as possible.

I’m eager to enable our audience with great user-centric docs and hope that you’ll join us as we fulfill the vision.

Tags: