Open Stack

Howdy Stackers,

I’ve created a summary etherpad [0] of the Queens retrospective session from the PTG and included a plain text export of it on this email.

Thank you to all who participated and please do add comments to the etherpad where I might have missed a perspective or interpretation in my attempt to summarize the session.

Best,
-melanie

[0] https://etherpad.openstack.org/p/nova-queens-retrospective-summary

*Queens Retrospective: Rocky PTG Summary

https://etherpad.openstack.org/p/nova-queens-retrospective

*Key topics

  * What went well
    * Volume multiattach support is now available for libvirt+lvm and with CI testing
    * Added Takashi Natsume to the python-novaclient core team
    * osc-placement 1.0.0 is now available, so operators have a CLI to interact with the Placement service (with docs too)
    * The run up to RC1 was much less stressful/hectic than it was in Ocata/Pike, we had fewer major changes leading up to the feature freeze
    * We have increased the number of people committing to placement related code
    * We had fewer approved and greater completed blueprints indicating we have gotten better at doing what we said we were going to do
    * We have sane defaults on AArch64 architecture (like UEFI being default, proper 'cpu_model')
    * The websocket proxy security finally landed
    * Kudos to Eric Fried for his work on nested resource providers in placement
    * Kudos to Chris Dent for his updates to the dev mailing list on placement
    * Kudos to Matt Riedemann for serving us as PTL for the past four cycles
  * What needs to improve
    * Concern around nova-core team expansion, or rather, lack of expansion and confusion/mystery about how to become a member of the core team
    * Problems around having dev conversations and gathering outcomes of those conversations
    * Non-priority spec/blueprint and bug fix code taking very long to merge and not getting visibility
    * Concern that not enough people participate in providing retrospective comments
    * Concern that we didn't actually merge things earlier in the cycle as decided during the Pike retrospective
    * Bug triage
    * Concern around time management and how to quickly get up-to-speed on what to review
    * We have had some unexpected changes in behavior in Ocata like the Aggregate[Core|Ram|Disk]Filter no longer working, that caused pain for operators

*Agreements and decisions
  * Make sure that people review osc-placement changes (I've added a section for this to the priorities etherpad [1])
  * melwitt will rewrite the nova contributor documentation about what the core team looks for in potential new core team members to be clear and concise (with some how-to tips), and increase its visibility by making sure it's more directly linked from the docs home page
  * On dev conversations that happen on IRC or on hangouts, have someone from the conversation write up a summary of the conversation (if there was an outcome) and send it to the dev mailing list with appropriate tags, for example "[nova][placement][...]". People should feel encouraged to use the dev mailing list to have dev conversations and communicate outcomes. Conversations needn't be limited to only IRC or hangouts
  * For the most part, the priorities etherpad [1] can provide visibility for non-priority spec/blueprint work and trivial bug fix code (there are sections for both of these: "Non-priority approved blueprints" and "Trivial bug subteam")
  * melwitt to write nova contributor documentation explaining the use of the priorities etherpad and link
  * We need a way to quickly point contributors at the documentation ^, suggestions include a bot that adds a comment to a new contributor's patch that points them to the documentation or a NEW_CONTRIBUTOR_README.rst in the root directory of the nova project that points to the documentation
  * Discuss the design and implement "runways" for blueprints where we focus review attention on selected blueprints for a specified time-box with the goal being to avoid approving new non-priority work until we've merged old non-priority work
  * Commit to fewer blueprints and complete a higher percentage of them. This is about fulfilling expectations and serving contributors better as opposed to setting goals too high and letting people down

On the other items:
  * At first, not many people added comments to the retrospective etherpad, but more people added comments as we got closer to the PTG, which was good. From what I can tell, most of the problems we have (including lack of participation in the retrospective etherpad) stem from a lack of communication, visibility, and transparency. It is my hope that diligent use of the priorities etherpad, runways, clear and concise documentation, and weekly reminders/summaries of the priorities etherpad will result in contributors seeing progress in their work and becoming more engaged.
  * The concern about how we decided we would merge things earlier in the cycle during the Pike retrospective but didn't actually follow through might be related to the item about difficulty around having dev conversations. This cycle, we've agreed to feel free to use the dev mailing list for dev conversations and communication of outcomes, so I hope that will result in obstacles being cleared more quickly and giving way to merging things earlier.
  * On bug triage, I'm going to spruce up documentation around the process and make sure it's linked near the nova dev documentation home page (currently I think it takes many clicks to find it). And I'm also thinking of doing weekly summaries and reminders to help people get engaged with bug triage.
  * On concern about time management and how to quickly find what to review, it is my hope that the priorities etherpad will be reviewers' "home page" for finding reviews and that a weekly summary/reminder will help keep it top-of-mind for everyone.
  * On the unexpected changes in Ocata causing operator pain, the Aggregate[Core|Ram|Disk]Filter behavior change was one that wasn't caught by our test coverage and was not intended to land without release notes/documentation or another solution. It was suggested that we could add test coverage where compute nodes are at capacity to catch issues with allocation ratios.

[1] https://etherpad.openstack.org/p/rocky-nova-priorities-tracking