OpenStack Developer Mailing List Digest March 19-25
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
Leave a Reply