Difference between revisions of "Meetings/Nova"
< Meetings
(→Agenda for next meeting) |
(→Agenda for next meeting) |
||
Line 86: | Line 86: | ||
** (IRC nickname) the topic you would want to discuss. | ** (IRC nickname) the topic you would want to discuss. | ||
** (astupnik) Known Issues section of Release Notes contains only known issues added during specific release cycle instead of complete list of known issues (all issues notes from nova/releasenotes/notes). I am wondering if this is normal or there is some bug in documentation framework? Example: min-bandwidth-workaround-0533ad03f67592a9.yaml introduced using I41f42c1a7595d9e6a73d1261bf1ac1d47ddadcdf and still affecting Nova. | ** (astupnik) Known Issues section of Release Notes contains only known issues added during specific release cycle instead of complete list of known issues (all issues notes from nova/releasenotes/notes). I am wondering if this is normal or there is some bug in documentation framework? Example: min-bandwidth-workaround-0533ad03f67592a9.yaml introduced using I41f42c1a7595d9e6a73d1261bf1ac1d47ddadcdf and still affecting Nova. | ||
+ | ** (jsanemet) Review API strategy for 'lock', 'migrate' and 'unshelve' actions. Coming from the following change: https://review.opendev.org/c/openstack/nova/+/875653, it was noted that while for older microversions the API requests are meant to look something like this: { 'lock' : null }, this other undocumented option is also accepted and used extensively by unit tests: { 'lock': {} }. Thing is, the documentation provided here: https://docs.openstack.org/api-ref/compute/#lock-server-lock-action only says that for older microversions the argument's value ought to be null, but not much else is specified in cases is it not. The change tries to fix a problem with so, in that the following: { 'lock': { 'foo': '...' } } was an accepted request that led to no effect on Nova. Now that will not be allowed, but from that comes the question on whether an empty dictionary should be allowed either or not. The same thing goes for the three actions. | ||
== Sub-teams == | == Sub-teams == |
Revision as of 09:02, 9 March 2023
Contents
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.
- #topic Release News
- #link Nova 2023.2 Bobcat schedule https://releases.openstack.org/bobcat/schedule.html
- #link Nova 2023.1 Antelope schedule https://releases.openstack.org/antelope/schedule.html
- #topic Stable branch status
- #link stable/2023.1: https://review.opendev.org/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/placement+OR+project:openstack/nova)+branch:stable/2023.1
- #link stable/zed: https://review.openstack.org/#/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/placement+OR+project:openstack/nova)+branch:stable/zed
- #link stable/yoga: https://review.openstack.org/#/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/placement+OR+project:openstack/nova)+branch:stable/yoga
- #link stable/xena: https://review.openstack.org/#/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/placement+OR+project:openstack/nova)+branch:stable/xena
- #link stable/wallaby is EM
- #topic Bugs (stuck/critical)
- #link bug triage how-to: https://wiki.openstack.org/wiki/Nova/BugTriage#Tags
- #help need help with bug triage
- #topic Gate status
- #link check queue gate status http://status.openstack.org/elastic-recheck/index.html
- #link 3rd party CI status (not so dead) http://ciwatch.mmedvede.net/project?project=nova
- #topic Review status page
- #link http://status.openstack.org/reviews/#nova
- Count: 438 (+20); Top score: 2303 (+21) (last refresh was 09-03)
- #help Pick a patch near the top, shepherd it to closure
Agenda for next meeting
Next meetings scheduled for:
- Mar 07 2023 16:00 UTC #openstack-nova (http://www.timeanddate.com/worldclock/fixedtime.html?iso=2023-03-07T16:00:00)
- Mar 14 2023 16:00 UTC #openstack-nova (http://www.timeanddate.com/worldclock/fixedtime.html?iso=2023-03-14T16:00:00)
- Mar 21 2023 16:00 UTC #openstack-nova (http://www.timeanddate.com/worldclock/fixedtime.html?iso=2023-03-21T16:00:00)
- Mar 28 2023 16:00 UTC #openstack-nova (http://www.timeanddate.com/worldclock/fixedtime.html?iso=2023-03-28T16:00:00)
Where you see "?" feel free to just edit the wiki and add your item.
Here is the agenda for the next meeting:
- #topic Bugs (stuck/critical)
- #info No Critical bug
- #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 14 new untriaged bugs (-3 since the last meeting)
- #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
- #info bug baton is being passed to elodilles
- #topic Gate status
- #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
- #link https://etherpad.opendev.org/p/nova-ci-failures
- #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status
- #info Please look at the gate failures and file a bug report with the gate-failure tag.
- #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures
- #topic Release Planning
- #link https://releases.openstack.org/antelope/schedule.html
- #info Antelope-rc1 was this Monday
- #link https://etherpad.opendev.org/p/nova-antelope-rc-potential
- #info Uggla and auniyal are the new release liaisons https://review.opendev.org/c/openstack/releases/+/876758
- #topic vPTG Planning
- #link https://www.eventbrite.com/e/project-teams-gathering-march-2023-tickets-483971570997 Register your free ticket
- #link https://etherpad.opendev.org/p/nova-bobcat-ptg Draft PTG etherpad
- #info we need to agree on the agenda and how many slots we book
- #topic Review priorities
- #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+(label:Review-Priority%252B1+OR+label:Review-Priority%252B2)
- #info As a reminder, cores eager to review changes can +1 to indicate their interest, +2 for committing to the review
- #topic Stable Branches
- #info stable/2023.1 branches were cut
- #info stable gates seem to be OK - though it's hard to merge patches due to intermittent failures
- #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
- #topic Sub/related team Highlights
- #info No subteam left
- #topic Open discussion
- (IRC nickname) the topic you would want to discuss.
- (astupnik) Known Issues section of Release Notes contains only known issues added during specific release cycle instead of complete list of known issues (all issues notes from nova/releasenotes/notes). I am wondering if this is normal or there is some bug in documentation framework? Example: min-bandwidth-workaround-0533ad03f67592a9.yaml introduced using I41f42c1a7595d9e6a73d1261bf1ac1d47ddadcdf and still affecting Nova.
- (jsanemet) Review API strategy for 'lock', 'migrate' and 'unshelve' actions. Coming from the following change: https://review.opendev.org/c/openstack/nova/+/875653, it was noted that while for older microversions the API requests are meant to look something like this: { 'lock' : null }, this other undocumented option is also accepted and used extensively by unit tests: { 'lock': {} }. Thing is, the documentation provided here: https://docs.openstack.org/api-ref/compute/#lock-server-lock-action only says that for older microversions the argument's value ought to be null, but not much else is specified in cases is it not. The change tries to fix a problem with so, in that the following: { 'lock': { 'foo': '...' } } was an accepted request that led to no effect on Nova. Now that will not be allowed, but from that comes the question on whether an empty dictionary should be allowed either or not. The same thing goes for the three actions.
Sub-teams
There are also some Nova subteam meetings. See Nova#Nova_subteams for details.