The OpenStack project stores the logs for all of the test jobs related to a commit on http://logs.openstack.org organized by the commit hash. To review the logs after a job runs, most developers start with the message jenkins leaves on gerrit, and click through to the log files. Not all jenkins jobs are triggered by or related to a gerrit review, though (e.g, release tags).

git-os-job makes it easy to find those logs by finding the hash of the commit and using it to build the right URL. It will then either print the URL or open a web browser directly.

What’s new in 1.1.1?

The OpenStack project stores the logs for all of the test jobs related to a commit on http://logs.openstack.org organized by the commit hash. To review the logs after a job runs, most developers start with the message jenkins leaves on gerrit, and click through to the log files. Not all jenkins jobs are triggered by or related to a gerrit review, though (e.g, release tags).

git-os-job makes it easy to find those logs by finding the hash of the commit and using it to build the right URL. It will then either print the URL or open a web browser directly.

Lately, I have been revising some of the OpenStack community’s processes to make them more sustainable. As we grew over the last 7 years to have more than 2,000 individual contributors to the current release, some practices that worked when they were implemented have begun causing trouble for us now that our community is changing in different ways. My goal in reviewing those practices is to find ways to eliminate the challenges.

OpenStack is developed by a collection of project teams, most of which focus on a feature-related area, such as block storage or networking. The areas where we have most needed to change intersect with all of those teams, such as release management and documentation. Although the teams responsible for those tasks have tended to be small, their members have been active and dedicated. At times that dedication has masked the near-heroic level of effort they were making to keep up with the work load.

When someone is overloaded in a corporate environment, where tasks are assigned and the performance and workload of team members are reviewed regularly, the employee can appeal to management for help. The solution may be to hire or assign new contributors, change the project schedule, or to make a short term trade-off that incurs technical debt. However, open source projects are largely driven by volunteers, so assigning people to work on a task isn’t an option. Even in a sponsor-driven community such as OpenStack, where many contributors are being paid to work on the project overall, sponsors typically give a relatively narrow mandate for the way their contributors can spend their time. Changing the project schedule is always an option, but if there are no volunteers for a task today, there is no guarantee volunteers will appear tomorrow, so it may not help.

We must use a different approach to eliminate the need for heroic effort.

On 23 January I received email from Disqus explaining that their new pricing structure is going into effect 8 February. These changes mean I am going to remove comments from all of my sites, at least for now.

Last week I spoke at the Atlanta OpenStack meetup about “Driving OpenStack via Ansible,” in which I introduced Ansible as a tool and talked about its ability to integrate with OpenStack. As part of the presentation I used two playbooks to launch VMs on a cloud and configure them with different applications. We walked through the playbooks and talked about what they were doing, the things that tripped me up while writing them, and then brainstormed ways to use Ansible in situations that have come up for members of the meetup.

One playbook uses my role to install ZNC, the popular IRC “bouncer,” for maintaining a persistent chat presence. The other demo was based on a playbook with the roles needed to configure a server for OpenStack development, ready to run devstack.

I’ve been a Python developer since the late 1990s and came to the OpenStack project from that long background within the rest of the community. Thierry Carrez is on the staff of the OpenStack Foundation and the chair of the OpenStack Technical Committee. He came to Python through OpenStack’s adoption of the language.

At EuroPython 2016, we delivered a presentation titled “How OpenStack Makes Python Better, and Vice-Versa”, discussing the history of the decision to use Python, our perspectives on how the two communities benefit each other, and how we can improve the relationship. The recording of the presentation, and the slides, are below.

As part of preparing for the talk I will be giving with Thierry Carrez at EuroPython 2016 next month, I wanted to put together a list of some of the projects members of the OpenStack community contribute to outside of things we think of as being part of OpenStack itself. I started by brainstorming myself, but I also asked the community to help me out. I limited my query to projects that somehow touched OpenStack, since what I am trying to establish is that OpenStack contributors identify needs we have, and do the work “upstream” in other projects where appropriate.

OpenStack has many facets, and as a result has pulled in contributors from many parts of the industry. A large number of them are also members of other open source communities, so it’s no surprise that even with only a few respondents to my question (most of them privately, off-list) we came up with a reasonably long list of other projects where we’ve made contributions. I did not make a distinction between the types of contributions, so this list includes everything from bug reports and triage to documentation to code patches for bug fixes or new features. In several cases, the projects came into existence entirely driven by OpenStack’s needs but have found wide adoption outside of our immediate community.

I’m excited to announce the final releases for the components of OpenStack Mitaka, which conclude the 6-month Mitaka development cycle.

You will find a complete list of all components, their latest versions, and links to individual project release notes documents listed on the new release site.

Congratulations to all of the teams who have contributed to this release!

I also want to extend a big thank you to Ajaeger and jhesketh for their help with build issues today, and to ttx and dims for their help with release work all this cycle and especially over the last couple of weeks.

Thank you!

Our next production cycle, Newton, has already started. We will meet in Austin April 25-29 at the Newton Design Summit to plan the work for the upcoming cycle. I hope to see you there!