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.



*Queens Retrospective: Rocky PTG Summary

*Key topics

  * What went well
    * Volume multiattach support is now available for libvirt+lvm and with CI 
    * 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 
    * 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 
    * 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 
    * 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.

OpenStack Development Mailing List (not for usage questions)

Reply via email to