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