[openstack-dev] 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-dev mailing list