OpenStack Developer Mailing List Digest March 19-25

The content below is taken from the original (OpenStack Developer Mailing List Digest March 19-25), to continue reading please visit the site. Remember to respect the Author & Copyright.

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

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

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

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

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

Semantic Version On Master Branches After Release Candidates

  • 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. With 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 distributions 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

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 discoverability .
  • Full thread

Posted on March 26 in category News

Tags: