[Openstack-operators] OpenStack Developer Mailing List Digest November 28 - December 4
Mike Perez
thingee at gmail.com
Fri Dec 4 20:43:31 UTC 2015
Perma link: http://www.openstack.org/blog/2015/12/openstack-developer-mailing-list-digest-november-20151128/
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].
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081351.html
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.
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2015-December/080938.html
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.
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081431.html
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].
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2015-December/080869.html
[1] - http://docs.openstack.org/ja/networking-guide/
[2] - https://review.openstack.org/#/c/226157/
[3] - https://review.openstack.org/#/c/243348/
[4] - https://review.openstack.org/#/c/209661/
[5] - http://docs.openstack.org/releases/releases/mitaka.html
[6] - https://bugs.launchpad.net/reno/+bug/1522153
[7] - https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
[8] - https://bugs.launchpad.net/cinder/+bug/1432387
[9] - https://review.openstack.org/#/c/241663/
[10] - https://review.openstack.org/#/c/239678/
[11] - http://eavesdrop.openstack.org/meetings/crossproject/2015/crossproject.2015-12-01-21.00.log.html#l-125
[12] - https://review.openstack.org/#/q/project:+openstack/openstack-specs,n,z
[13] - https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
More information about the OpenStack-operators
mailing list