The content below is taken from the original (OpenStack Developer Mailing List Digest November 28 to December 4), to continue reading please visit the site. Remember to respect the Author & Copyright.

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 (13.0.0.0b1) 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].

The content below is taken from the original (Announcing a new cloud provider for OpenStack’s CI system: OVH), to continue reading please visit the site. Remember to respect the Author & Copyright.

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.

The content below is taken from the original (Technical Committee Highlights November 27, 2015), to continue reading please visit the site. Remember to respect the Author & Copyright.

Welcome back from Tokyo. While there, I did not realize a three-dimensional subway map exists for Tokyo, but I sure loved traveling on the subway.

Welcoming the latest projects to OpenStack

Speaking of amazing cities and their subway maps, we should mention the growing list of OpenStack projects. We welcome these projects to OpenStack governance since the OpenStack Summit.

• Monitoring – both OpenStack and its resources: monasca
• Backups for file systems using OpenStack: freezer
• Deployment for OpenStack: fuel
• Cluster management service for Compute and Orchestration: senlin
• Integrate Hyper-V, Windows and related components into OpenStack: winstackers

During these last weeks, the TC also had other project reviews requests that were put on hold for later once those projects and/or teams are more mature and ready to join the Big Tent.

Reports from TC Working Groups

Project Team Guide

The Project Team Guide team held a session back in Tokyo to discuss the next steps for this project. As a result of that session, more content will be created (or moved from the wiki): add community best practices, detail the benefits and trade-offs of the various release models, introduce deliverables and tags (as maintained in the governance repo’s projects.yaml), detail what common infrastructure projects can build on, and so on.

Communications Group

The communications working group (the one that brings these blog posts to you) will continue to operate under the same model. Announcements, summaries and communications will be sent out as they have been during the last cycle. Remember that feedback is always welcome and the group is looking for ways to improve. Talk back to us, we’re listening!

Project Tags

These are the latest new project tags created by the Technical Committee.

• team:single-vendor: A new tag was added to communicate when a project team is currently driven by a single organization. We had some discussion about using the term “vendor” or “organization” but this intent is to show the opposite of a diversity in the team’s makeup.
• assert:supports-upgrade: A new tag has been added to communicate when a project supports upgrades. Teams should apply this tag to their project if they assert they intend to support ongoing upgrades.
• assert:supports-rolling-upgrade: A new tag has been added to communicate when a project supports rolling upgrades. Team should apply this tag to their project if they assert that operators can expect to perform rolling upgrades of their project, where the service can remain running while the upgrade is performed.