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

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].

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.

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.

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].