Jump to: navigation, search


< Meetings
Revision as of 15:59, 19 July 2022 by Sylvain-bauza (talk | contribs) (Agenda for next meeting)

Weekly Nova team meeting

Regular MEETING TIME: Tuesdays 16:00 UTC (#openstack-nova on OFTC)

This meeting is a weekly gathering of developers working on OpenStack Compute (Nova). We cover topics such as release planning and status, bugs, reviews, and other current topics worthy of real-time discussion.

Project Heartbeat

This information will be updated weekly but not mentioned in the meeting unless specifically called out on the agenda.

Agenda for next meeting

Next meetings scheduled for:

Where you see "?" feel free to just edit the wiki and add your item.

Here is the agenda for the next meeting:

  • #topic Stable Branches
    • #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
    • #info stable/train is blocked, fix exists but hasn't merged yet due to intermittent failures + now nova-grenade-multinode & nova-live-migration started to fail @ devstack 'create' phase
  • #topic Sub/related team Highlights
    • #info No subteam left
  • #topic Open discussion
    • (bauzas) Opportunities for low-hanging-fruits, anyone ? (to be punted to next week)
    • (sean) https://review.opendev.org/c/openstack/nova-specs/+/849488 spec freeze exception for spice compression
    • (sean) there seams to be considerable outstanding question with regards to Configurable instance domains

"https://review.opendev.org/c/openstack/nova-specs/+/849765" to the point that i belive we should revert this. the question i then have is do we think we could come to an agreement before the next meeting on the open point (e.g. if we granted a spec freeze exception could we reasonable address the out standing issues) or should we defer this to AA so that we have time to evaluate this fully. The main concerns are rolling upgrades, is this in scope of nova, the ux between neutron and nova domain name configuration ("i already told neutron what domain to use why should i have to tell nova" vs " if i tell nova i don't need to configure neuton isn't that simpler") in aggregate I'm actually leaning towards taking a step back and revauating all options for step 0 incldueing reverting or sanitisation fo display names and allowing FQDNs in the hostname filed. i.e. should we have truncated instead of normalising as we do for unicode, should we allow the fqdn in the host name field but truncate it when setting dns_name on neutron ports. should we have a neutron extion to mark a port as the "primary domain". we had ruled out test options in the past at different point but we seam to have reached an impass where all options have negatives and we dislike them for different reason so we may need to evaluate them again with that new context. https://review.opendev.org/c/openstack/nova-specs/+/850048 revert proposed here


There are also some Nova subteam meetings. See Nova#Nova_subteams for details.

Previous meetings