Open Stack

HTML version: http://www.openstack.org/blog/2016/03/openstack-developer-mailing-list-digest-20160318-2/

SuccessBot Says
===============
* redrobot: The Barbican API guides is now being published. [1]
* jroll: ironic 5.1.0 released as the basis for stable/mitaka.
* ttx: All RC1s up for milestones-driven projects.
* zara: storyboard.openstack.org sends emails now!
* noggin143: my first bays running on CERN production cloud with Magnum.
* sdague: Grenade upgraded to testing stable/liberty -> stable/mitaka and
  stable/mitaka -> master.
* Tell us yours via IRC with a message “#success [insert success]”.
* All: https://wiki.openstack.org/wiki/Successes


PTL Election Conclusion and Results
===================================
* Results are in, congrats to everyone! [2]
* Appointed PTLs by the TC for leaderless Projects [3]:
  - EC-API: Alex Andrelevine
  - Stable Branch Maintenance: Tony Breeds
  - Winstackers: Claudiu Belu
Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/090422.html


Candidate Proposals for Technical Committee Positions Are Now Open
===================================================================
* Important dates:
  - Nominations open: 2016-03-25 00:00 UTC
  - Nominations close: 2016-03-31 23:59 UTC
  - Election open: 2015-04-01 00:00 UTC
  - Election close: 2015-04-07 23:59 UTC
* More details on the election [4]
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/090421.html


Release countdown for week R-1, Mar 27 - Apr 1
==============================================
* Focus:
  - Project teams following the cycle-with-milestone model should be testing
    their release Candidates.
  - Project teams following the cycle-with-intermediary model should have at
    least one Mitaka release and determine if another release is needed before
    the end of the Mitaka cycle.
  - All projects should be working on release-critical-bugs.
* General Notes:
  - Global-requirements list is still frozen.
  - If you need to change a dependency for release-critical-bug fix, provide
    enough details in the change request.
  - Master branches for all projects following cycle-with-milestone are open
    for Newton development work.
* Release Actions:
  - Projects following cycle-with-intermediary without clear indication of
    cutting their final release:
    + bifrost
    + magnum
    + python-searchlightclient
    + senlin-dashboard
    + solum-infra-guestagent
    + os-win
    + cloudkitty
    + tacker
  - These projects should contact the release team or submit a release request
    to the releases repository as soon as possible. Please submit a request by
    Wednesday or Thursday at the latest.
    + After March 31st, feature releases will be counted as part of Newton
      cycle.
  - The release team will have reduced availability between R1 and summit due
    to travel. Use the dev mailing list to contact the team and include
    "[release]" in the subject.
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/089701.html


Bots and Their Effects: Gerrit, IRC, other
==========================================
* Bots are very handy for doing repetitive tasks.
* These require require permissions to execute certain actions, require
  maintenance to ensure they operate as expected and do create output which is
  music to some and noise to others
* From an infra meeting [5], this is what has been raised so far:
  - Permissions: having a bot on gerrit with +2 +A is something we would
    like to avoid
  - "unsanctioned" bots (bots not in infra config files) in channels
    shared by multiple teams (meeting channels, the -dev channel)
  - Forming a dependence on bots and expecting infra to maintain them ex
    post facto (example: bot soren maintained until soren didn't)
  - Causing irritation for others due to the presence of an echoing bot
    which eventually infra will be asked or expected to mediate
  - Duplication of features, both meetbot and purplebot log channels and host
    the archives in different locations
  - Canonical bot doesn't get maintained
* It's possible bots that infra currently maintains have features that folks
  are unaware of.
* Bots that +2 reviews and approve them can be a problem when taking into
  account of schedules, outages, gate issues, etc.
* The Success bot for example is and added feature that takes advantage of the
  already existing status bot.
* What are the reasons that people end up writing their own bots instead of
  contributing to the existing infrastructure bots when applicable?
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/thread.html#90262


Semantic Version On Master Branches After RC
============================================
* The release team assumes three options someone would choose when installing
  things:
  - Tagged versions from any branch.
    + Clear, and always produces deployments that are reproduceable, with
      versions distinct and increasing over time.
  - Untagged versions on a stable branch.
  - Untagged versions on the master branch
    + Options 2 and 3 are something around release cycle boundaries.
    + Produce the same version numbers in different branches for a short period
      of time.
    + The release team felt it was extremely unlikely that anyone would mix
      option 2 and 3, because that will make upgrades difficult.
* Some distributions want to package things that are not tagged as releasable
  by contributors.
  - Consumers
    + They are in their development cycles and want/need to keep up with trunk
      throughout the whole cycle.
    + A lot of changes are introduced in a cycle with new features,
      deprecations, removals, non-backwards compatibility etc. Wit these
      continually provided up-to-date packages, they are able to test them
      right away.
  - It's a lot of work to package things, and distributions want to do it
    quickly.
    + If distributions started packaging OpenStack only when the official
      stable release would be out, it would take us several weeks/months to get
      a stable package out.
    + Projects that use packages to deploy are then delayed for their own
      release to test these packages their consuming. (e.g. TripleO, Packstack,
      Kolla, Puppet-OpenStack).
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/thread.html#90149


Our Install Guides Only Cover Defcore - What About Big Tent?
============================================================
* Until recently, projects like Manila [6] and Magnum have been accepted in the
  install guides, but we're having issues initially because they aren't
  considered by the defcore working group.
  - With expansion of projects coming from big tent, the documentation team has
    projects requesting their install documentation to be accepted. The
    documentation team today maintain and verifies the install documentation
    for each release can be a lot of work with the already accepted OpenStack
    projects.
* Goals:
  - Make install guides easy to contribute for projects in the big tent.
  - Not end up having the documentation team maintain all projects install
    documentation.
  - As an operator, I should be able to easily discover install documentation
    for projects in the big tent.
  - With accessible install documentation projects can hopefully have:
    + Improved adoption
    + More stable work from bug reports with people actually able to install
      and test the project.
* Proposal: Install documentation can live in a project's repository so they
  can maintain and update.
  - Have all these documentation sources rendered to one location for easy
    discoveribility.
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/thread.html#90214


[1] - http://developer.openstack.org/api-guide/key-manager/
[2] - http://lists.openstack.org/pipermail/openstack-dev/2016-March/090422.html
[3] - http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-03-22-20.01.html
[4] - https://wiki.openstack.org/wiki/TC_Elections_April_2016
[5] - http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-03-22-19.02.log.html
[6] - https://review.openstack.org/#/c/213756/