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


This month, the 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 site?

You might know that the site documents over 900GET/PUT/POST/DELETE/PATCH calls for a dozen OpenStack services already on the 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

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.


OpenStack Developer Mailing List Digest January 2-8

SuccessBot Says

  • russellb: Ported OVS to Python 3.
  • notmyname: Removed the beta tag on the swift erasure code docs.
  • AJaeger: OpenStack configuration reference has been migrated from DocBook XML to RST [1].
  • notmyname: This season’s Outreachy intern had her first patch merged.
  • odyssey4me: OpenStack-Ansible 12.0.3 tagged.
  • jordanP: My 3rd party CI correctly warned me that a patch would break my driver.
  • asselin: OpenStack Third Party CI documentation published [2].

Slightly Longer Delays for Gate CI Testing

  • When: January 31, 2016
  • Why:
    • Due to the sunsetting of a public cloud [3] used by the OpenStack Infra team, we will have less resources available.
    • Jeremy Stanley says that the Infra team is working on bringing in new providers to absorb the impact.

Release Countdown For Week R-12, Jan 11-25

  • Focus:
    • Second milestone is coming up. Finish up major features or reevaluate if it really needs to land in this cycle.
  • Actions:
    • Identify work that needs to be completed before the M-2 tag.
    • Release liaisons responsibilities are being updated. Provide comments for questions or concerns [4].
  • Important Dates:
    • Mitaka 2: Jan 19-21
    • Release schedule [5].

Re-introduce Twisted to global-requirements

  • A change in global-requirements introduces mimic, an http server that can mock various APIs.
  • Mimic depends on twisted, which in the past was removed in favor of Eventlet to avoid developers having to know multiple frameworks [5].
  • Jim Rollenhagen explains Ironic’s need for Mimic:
    • To do functional tests, not unit tests which they could do with requests-mock.
    • To bring up a less expensive Ironic environment for doing these tests.
  • Jay Pipes notes:
    • This is another way to introduce a larger surface area of bugs to creep in since you have keep Mimic up-to-date with the real interfaces.
    • There’s not a clear value in the advantage  of functional tests of a client that calls a fake HTTP API versus unit tests of a client that simply uses requests-mock.

OpenStack Community Newsletter (Dec. 12-22)

Running an OpenStack cloud? Come to the first European Mid-Cycle Operators meetup

The meetup, held February 15 – 16, 2016 in Manchester, is a chance for operators to share best practices and give feedback.

The keys to OpenStack startup success: Platform9 Systems

Platform9 Systems opens its startup playbook, highlighting ecosystem challenges and tips for fellow startups including how they differentiate their product from competitors with simplicity, choice and interoperability.

OpenStack operators connecting together

To make meetups more productive and useful, Edgar Magana at Workday proposes smaller, operator-focused gatherings.

The Road to Austin

Community feedback

OpenStack is always interested in feedback and community contributions, if you would like to see a new section in the OpenStack Weekly Community Newsletter or have ideas on how to present content please get in touch: [email protected].

CFP Deadlines

OpenStack Developer Mailing List Digest December 12-18

Tips ‘n Tricks 

Upcoming Events 

Other News

OpenStack Developer Mailing List Digest December 12-18

Success Bot Says

  • jroll: Ironic is using the devstack plugin.
  • Tell us yours via IRC with a message “#success [insert success]”.

Cross-Project Specs

  • Approved by the Technical Committee:
    • Chronicles Of A DLM [1].
      • OpenStack will adopt Tooz as an abstract layer to distributed lock managements solutions. This will allow projects to provide all the options Tooz provides for their distributed lock management needs.
      • Reference implementation is currently ZooKeeper for testing.
  • Close to approval:
    • Backwards compatibility for libraries and clients [2].
    • Deprecate individual CLIs in favor of OSC [3].

New Things In Gerrit 2.11 To Enjoy

  • New search strings:
    • Patch size
      • delta:<=10
      • show patches with <= 10 lines of change
    • Scoring by group
      • label:Code-Review<=-1,nova-core
      • filter by -1 from nova-core team
    • message:/comment:
      • Queries work with more than one word
  • UI Features:
    • is:amergable field
    • Column 3
      • Related changes: all changes in linear patch series.
      • Conflicts with: all open patches in the system that will conflict with this one.
      • Same topic: Grouping reviews.
    • Inline edit an entire patch.
      • Click the ‘edit’ button above the list of files. Once you’re done click ‘save’ and eventually ‘Publish Edit’ on the main page.
      • “Follow up” button: builds an entire follow up patch that you can inline edit to fix something like typos.

Stable Meeting Time Proposal

DocImpact vs. Reno

  • Sean notes a new job on all Nova changes that is processing commit messages [5].
  • UpgradeImpact got dropped for having an upgrade comment in Reno.
  • Instead of DocImpact, SecurityImpact in commit messages, new special sections using Reno will be created that trigger creating bugs and sending out emails like today. The hope is for better quality in these notifications.

Nominations open for the N and O names of OpenStack

  • For the N release, where the geographic region is “Texas Hill Country” [6]
  • For the O release, where the geographic region is “Catalonia” [7]
  • OpenStack foundation individual members should have received a vote link via email. [8]
  • Polls end of Dec 22nd UTC.

OpenStack Weekly Community Newsletter (Dec. 5-11)

Travel grants bring global community members to OpenStack Summit

Key contributors from 15 countries attended the recent OpenStack Summit in Tokyo. The program for Austin is growing – find out more about the Travel Support Program.

OpenStack Mitaka release: what’s next for Neutron, Cinder and Ceilometer

Meet the project team leads (PTLs) and find out how to get involved.

Check out this tool library for OpenStack operators

These tools – contributed by and for operators – offer quick solutions to streamline your work

OpenStack design contest T-shirts are now available!

Joline Buscemi won the third edition of the community T-shirt design contest, held annually by the OpenStack Foundation.

Community feedback

OpenStack is always interested in feedback and community contributions, if you would like to see a new section in the OpenStack Weekly Community Newsletter or have ideas on how to present content please get in touch: [email protected].

CFP Deadlines

OpenStack Developer Mailing List Digest December 5-11

Tips ‘n Tricks 

Upcoming Events 

Other News

OpenStack Developer Mailing List Digest December 5-11

Success Bot Says

  • AJaeger: With Juno End-of-Life, Python 2.6 testing has been removed from OpenStack CI.
  • Tell us yours via IRC with a message “#success [insert success]”.

Gerrit Update 12/16

  • Gerrit will be offline December 16th 17:00-21:00 UTC
  • Gerrit will be upgraded to 2.11
  • IP address will stay the same.
  • For questions, reply to the thread or on IRC #openstack-infra.

Release Countdown For Week R-17, Dec 7-11

  • Focus should be on cross-project themes identified a the summit [1], and whether any work needs to be done to address them in your project.
  • Doug Hellmann will be offline until December 21st. The rest of the release management team will able to assist via:
    • IRC #openstack-release
    • Mailing list with “[release]” in the subject.
  • Release actions:
    • If the Liberty release notes page [2] doesn’t have a link to your project’s release notes, submit a patch to your deliverable file in openstack/releases.

Bugs Will Now Close Automatically When Patches Merge

  • Part of deprecating our use of Launchpad for tracking completed work, when a patch with “Fixes-Bug” in the commit message merges, the bug will move to ‘Fixed Released” instead of “Fix Committed”.

Cleaning Up Deprecation Warnings in the Gate

  • We have a lot of logs to process in our elastic search cluster, which results in frequently having issues with the amount of RAM available in the cluster.
  • In general it would be good for projects to look at how verbose their logging is, and if that’s really necessary.
  • Using this query [3] to show deprecation warnings on jobs running on master the past 7 days shows 17576707 hits.
  • We need volunteers to to make changes in things like Devstack to have it avoid using deprecated options.
    • If you would like to help, please use the topic ‘stop-using-deprecated-options’ [4].

Stable Team PTL Elected

  • Close to 200 voters have elected Matt Riedmann as the first stable team PTL [5].
  • Matt will be looking into meeting times next week to begin discussions on transitioning from release team and work items.

Announcing the OpenStack Health Dashboard

  • A dashboard to visualize the state of tests running in gate [6].
  • Started last September, it’s still in early phases.
  • Biggest limitations:
    • The datastore: using subunit2sql as the backend for all data and only collecting results for tempest and grenade runs in the gate and periodic queues.
    • No results for runs that fail before tempest starts running.
  • Code [7]
  • Launchpad [8]
  • Work items that need to be done [9].

OpenStack Weekly Community Newsletter (Nov. 28 – Dec. 4)

Individual Member Director nominations are now open

The deadline for Individual Member Director nominations is next Friday, December 11, 2015

How to manage medical and health data with OpenStack, a wearable sensor and smart apps

“Our hope is to inspire you to look into open source, to think of ways to solve the data problems that you might have already,” says Anne Gentle of Rackspace.

Why no data center should be full of islands

OpenStack connects developers with new tools while leveraging a common foundation, says Foundation COO Mark Collier.

Powering one billion page views and 170 million unique visitors per month with OpenStack

NTT Resonant operates goo, one of Japan’s leading web portals and Internet search engines

Community feedback

OpenStack is always interested in feedback and community contributions, if you would like to see a new section in the OpenStack Weekly Community Newsletter or have ideas on how to present content please get in touch: [email protected].

Reports from Previous Events 

CFP and Election Deadlines

OpenStack Developer Mailing List Digest November 28 to December 4

Tips ‘n Tricks 

Upcoming Events 

Other News

OpenStack Developer Mailing List Digest November 28 to December 4

Success Bot Says

  • dims: cross-project, technical-debt-reduction effort pays dividends, no code left in oslo-incubator repo anymore.
  • dhellmann: horizn, searchlight, python-openstackclient, ironic-introspec, manila, barbican, aodh, and sahara tagged for mitaka-1 milestone!
  • odyssey4me: OpenStack-Ansible for Kilo and Liberty have been released.
  • ttx: Nova mitaka-1 ( published!
  • flaper87: Glance m-1 is out
  • AJaegar: The Networking Guide has been translated into Japanese, read it [1].
  • stevemar: Got reno in all keystone projects.
  • Tell us yours via IRC with a message “#success [insert success]”.

Cross-Project Specs Close to Merging

  • Backwards compatibility for clients and libraries [2].
  • Deprecate Individual CLIs in favor of OpenStack Client [3].
  • Chronicles of Distributed Lock Manager [4].

Release Countdown For Week R-17, Dec 7-11

  • A list of all projects with tags [5].
  • There’s a known bug in Reno for release notes not appearing after merge [6].
  • Teams should have retrospectives to consider how the cycle is going so far.
  • Each project has a patch that removes the version field from setup.cfg file. Please review that as quickly as possible.
  • Mitaka 2 Release: Jan 19-21
  • Mitaka release schedule [7].

The Lock Files Saga (and Where We Can Go From Here)

  • Josh Harlow writes, different projects use file locks to ensure that no application on the same machine can manipulate a given resource.
  • Stale lock file bug happens [8] and there is no easy way to determine when a lock file can be deleted manually.
  • Proposed creative solutions [9][10].
  • Josh proposes having offset locks. Create a single file X size to store locks, instead of having a bunch of files representing locks.
    • Clint says this just makes the directory of lock files look clean, but still leaves each offset stale and has to cleaned anyway.
      • Idea: having a cron job which deletes lock files within a set reasonable time.
  • Ben Nemec feels this is largely cosmetic complaints about not cleaning up old files. The amount of trouble we’ve had with interprocess locking in the past, he has never felt that a cosmetic issue was sufficient reason to relook at the issue.
  • Clint feels what’s missing is metadata for cleaning up stale locks. That can be done with:
    • fcntl locks – You have the kernel telling you for sure if the locking process is still alive when you want to clean up and take the lock.
    • Creation locks – You need to write that information into the locks, and remove it, and then have a way to make sure the process is alive and know it has the lock, which isn’t simple.

Recording Milestones For Unmanaged Projects

  • Projects with non-release:managed tag should:
    • Prepare a patch to the deliverable file in openstack/releases repository recording the existing beta tag for your release. Include in the commit message that you are recording an existing milestone tag.
    • Prepare a patch to the project repository removing the version line from setup.cfg. This patch should depend on the release patch with the topic “remove-version-from-setup”.
    • Add a comment to the milestone tag request linking to the review from step 2.

Cross-Project Spec Liaisons

  • Mike Perez writes about problems we have with cross-project specs today:
    • Authors of specs can’t progress forward with specs because of lack of attention. Eventually getting frustrated and giving up.
    • Some projects could miss a cross-project spec being approved by the TC.
  • A proposal was given on the list and discussed at the cross-project meeting [11] to have cross-project spec liaisons from each project with the following responsibilities:
    • Watching the cross-project spec repo [12].
      • Comment on specs that involve your project. +1 to carry forward for TC approval.
        • If you’re not able to provide technical guidance on certain specs for your project, it’s up to you to get the right people involved.
        • Assuming you get someone else involved, it’s up to you to make sure they keep up with communication.
  • Communicate back to your project’s meeting on certain cross-project specs when necessary. This is also good for the previous bullet point of sourcing who would have technical knowledge for certain specs.
  • Attend the cross-project meeting when it’s called for [13].

Announcing a new cloud provider for OpenStack’s CI system: OVH

The OpenStack Project Infrastructure Team has added OpenStack Compute instances from OVH to the project’s continuous integration system.

There are a lot of ways to participate in an Open Source community like the OpenStack project and OVH is doing so in a way that best matches their strengths: contributing cloud resources to the project to drive our test and automation systems — resources which are critical to ongoing development.

OpenStack runs up to 30,000 automated jobs each day to test proposed changes and build documentation and software artifacts. The system responsible for this is itself a large multi-cloud application. It utilizes OpenStack Compute instances from Rackspace, HP Cloud, and now OVH to provide this service to developers. Each of those instances runs a single job and is then deleted in order to ensure the next job starts with a clean slate. This puts an extraordinarily high demand on our providers.

We are very excited by the addition of OVH, not only because it will help us scale to meet the needs of a growing project, but also because it demonstrates one of OpenStack’s key features: cross-cloud compatibility. When a developer uploads a proposed change to an OpenStack project, available instances from any of our contributing cloud providers will be used interchangeably to test it.

We are able to do this with the help of a number of OpenStack projects. First, we create a base image to use on all of our providers using Diskimage-builder. This ensures that all of our tests operate in an identical environment. Our test resource manager, Nodepool, uses the shade library to upload each of these images to our providers using the OpenStack Image service. Each of our providers is configured slightly differently, but shade handles the details so that Nodepool can focus on the business logic. Nodepool then identifies demand from our automation system, Zuul, to create OpenStack Compute instances as needed.

The Infrastructure Team thanks OVH for their contribution as well as our existing cloud providers, and we are excited about sharing our experience using this very demanding OpenStack application with all of them.