| *** efried1 is now known as efried | 02:04 | |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Add functional regression tests for bug 1857306 https://review.opendev.org/c/openstack/nova/+/700456 | 03:24 |
|---|---|---|
| opendevreview | Rajesh Tailor proposed openstack/nova master: Handle InstanceExists exception for duplicate instance https://review.opendev.org/c/openstack/nova/+/860938 | 03:25 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Handle InstanceExists exception for duplicate instance https://review.opendev.org/c/openstack/nova/+/860938 | 03:40 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Handle InstanceExists exception for duplicate instance https://review.opendev.org/c/openstack/nova/+/860938 | 04:15 |
| bauzas | gibi: you may give a shoot for the 2023.1 stable branch (11:52:45) opendevreview: OpenStack Release Bot proposed openstack/placement stable/2023.1: Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/placement/+/875873(11:52:45) opendevreview: OpenStack Release Bot proposed openstack/placement stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/placeme | 08:27 |
| bauzas | nt/+/875874(11:52:45) opendevreview: OpenStack Release Bot proposed openstack/placement master: Update master for stable/2023.1 https://review.opendev.org/c/openstack/placement/+/875875 | 08:27 |
| bauzas | (10:23:22) opendevreview: OpenStack Release Bot proposed openstack/nova stable/2023.1: Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/nova/+/876551(10:23:27) opendevreview: OpenStack Release Bot proposed openstack/nova stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/nova/+/876552(10:23:31) opendevreview: OpenStack Release Bot proposed openstack/ | 08:27 |
| bauzas | nova master: Update master for stable/2023.1 https://review.opendev.org/c/openstack/nova/+/876553 | 08:27 |
| bauzas | gibi: context is better shown here https://etherpad.opendev.org/p/nova-antelope-rc-potential#L43 | 08:27 |
| bauzas | elodilles: we may have a situation with the antelope release notes https://zuul.opendev.org/t/openstack/build/9bf4ebd3d6a64530ac40d43acd029f01 | 08:29 |
| * bauzas wonders why unrelease.rst wasn't popping up the isse | 08:29 | |
| elodilles | :S | 08:34 |
| elodilles | bauzas: it did not pop up with unreleased.rst as we did not have a sorting problem until we started again the alphabet (or in this case, with "2023.1") | 08:36 |
| elodilles | there is a workaround proposed in reno: https://review.opendev.org/c/openstack/reno/+/876581 | 08:37 |
| opendevreview | Jorge San Emeterio proposed openstack/nova master: Adding a default schema for requests to the 'lock', 'migrate' and 'unshelve' actions. https://review.opendev.org/c/openstack/nova/+/875653 | 08:38 |
| bauzas | elodilles: damn shit | 08:38 |
| bauzas | gtk | 08:38 |
| opendevreview | Justas Poderys proposed openstack/nova-specs master: Add support for Napatech LinkVirt SmartNICs https://review.opendev.org/c/openstack/nova-specs/+/859290 | 08:58 |
| opendevreview | Jorge San Emeterio proposed openstack/nova master: DNM: Checking reliability of "test_tagged_attachment" test. https://review.opendev.org/c/openstack/nova/+/876699 | 09:07 |
| opendevreview | ribaudr proposed openstack/nova-specs master: Re-propose "Allow Manila shares to be directly attached to an instance when using libvirt" for Bobcat https://review.opendev.org/c/openstack/nova-specs/+/876706 | 09:34 |
| Uggla | bauzas, see ^ | 09:35 |
| opendevreview | ribaudr proposed openstack/nova-specs master: Re-propose "Allow local scaphandre directory to be mapped to an instance using virtiofs" for Bobcat https://review.opendev.org/c/openstack/nova-specs/+/876707 | 09:45 |
| Uggla | bauzas, ^ | 09:45 |
| bauzas | Uggla: ack and ack | 09:52 |
| bauzas | Uggla: well, you shouldn't move the approved spec file | 09:53 |
| bauzas | Uggla: just create a new file :) | 09:53 |
| Uggla | oh sh.... | 09:53 |
| Uggla | ok I'm gonna fix that | 09:54 |
| bauzas | Uggla: no worries: ) | 09:54 |
| bauzas | Uggla: tbc, we only move a spec file if the spec wasn't accepted, ie. when the file isn't yet merged | 09:55 |
| bauzas | but when the spec is accepted, then the file is merged, so operators can see it by https://specs.openstack.org/openstack/nova-specs/specs/2023.1/approved/ | 09:56 |
| bauzas | so we need to leave it there and then copy the file to the other 2023.2 directory by the new change | 09:57 |
| bauzas | hth | 09:57 |
| opendevreview | ribaudr proposed openstack/nova-specs master: Re-propose "Allow Manila shares to be directly attached to an instance when using libvirt" for Bobcat https://review.opendev.org/c/openstack/nova-specs/+/876706 | 10:02 |
| opendevreview | ribaudr proposed openstack/nova-specs master: Re-propose "Allow local scaphandre directory to be mapped to an instance using virtiofs" for Bobcat https://review.opendev.org/c/openstack/nova-specs/+/876707 | 10:07 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: DNM (yet) Update min support for Bobcat https://review.opendev.org/c/openstack/nova/+/875621 | 10:26 |
| gibi | bauzas: I guess we want to merge ^^ now | 10:26 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Update min support for Bobcat https://review.opendev.org/c/openstack/nova/+/875621 | 10:27 |
| bauzas | gibi: yeah I need to respin | 10:27 |
| bauzas | oh | 10:27 |
| gibi | I did the respin :) | 10:27 |
| bauzas | I need to verify a thing | 10:27 |
| gibi | if zuul will be happy then I will | 10:27 |
| gibi | bauzas: ack | 10:27 |
| bauzas | the grenade-skip-level-continuous job | 10:28 |
| bauzas | dansmith had a change for adding it in nova | 10:28 |
| bauzas | and I'd like us to clarify what job we gonna make voting in Bobcat which is non-SLURP | 10:28 |
| opendevreview | Merged openstack/placement stable/2023.1: Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/placement/+/875873 | 13:33 |
| opendevreview | Merged openstack/placement stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/placement/+/875874 | 13:33 |
| bauzas | \o/ | 13:33 |
| bauzas | gibi: I need to work on https://review.opendev.org/c/openstack/nova/+/875621 | 13:35 |
| bauzas | gibi: because of https://fb9f1a762c721749bb72-4adf110539aed9252479dc6b548d2884.ssl.cf5.rackcdn.com/875621/9/check/nova-tox-functional-py38/7df3e76/testr_results.html | 13:35 |
| gibi | yeah probably we need an extra mock there | 13:36 |
| gibi | as it tries to start an old compute in an env that has newer one | 13:37 |
| bauzas | gibi: two possibilities : either we delete those tests, or we punt the new compute service version to be Antelope | 13:37 |
| gibi | sorry in an env that declares that we does not support that old computes any more | 13:38 |
| bauzas | (in the tests) | 13:38 |
| gibi | It would be nice to know why these tests need an old Antelope compute | 13:39 |
| gibi | old Yoga | 13:39 |
| gibi | compute | 13:39 |
| bauzas | gibi: I guess because they provided a new RPC API version | 13:39 |
| bauzas | so they verify this works with older computes | 13:39 |
| bauzas | (and I like this) | 13:39 |
| bauzas | but they haven't pinned the new compute service | 13:39 |
| bauzas | so basically it just uses the latest service version | 13:40 |
| gibi | can we pin RPC version without pinning the service version? | 13:41 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.share_attach_error notification https://review.opendev.org/c/openstack/nova/+/860282 | 13:46 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.share_detach_error notification https://review.opendev.org/c/openstack/nova/+/860283 | 13:46 |
| opendevreview | ribaudr proposed openstack/nova master: Add share_info parameter to resume method for each driver (driver part) https://review.opendev.org/c/openstack/nova/+/860284 | 13:46 |
| opendevreview | ribaudr proposed openstack/nova master: Support resuming an instance with shares (compute and API part) https://review.opendev.org/c/openstack/nova/+/860285 | 13:46 |
| opendevreview | ribaudr proposed openstack/nova master: Add helper methods to rescue/unrescue shares https://review.opendev.org/c/openstack/nova/+/860286 | 13:46 |
| opendevreview | ribaudr proposed openstack/nova master: Support rescuing an instance with shares (driver part) https://review.opendev.org/c/openstack/nova/+/860287 | 13:46 |
| opendevreview | ribaudr proposed openstack/nova master: Support rescuing an instance with shares (compute and API part) https://review.opendev.org/c/openstack/nova/+/860288 | 13:46 |
| opendevreview | ribaudr proposed openstack/nova master: Documentation https://review.opendev.org/c/openstack/nova/+/871642 | 13:46 |
| Uggla | gibi, bauzas I think I have fixed all comments on the virtiofs RFE. So you can have a look as soon as you want. | 14:14 |
| bauzas | ++ | 14:15 |
| bauzas | yeah I'll quickly approve your spec | 14:15 |
| bauzas | and then I'll restart to look at your series | 14:15 |
| gibi | Uggla: cool. Please remind me periodically about it as my priorities is all over the place. | 14:25 |
| Uggla | gibi, I don't want to bother you too much, but I'll remind you once needed. | 14:28 |
| gibi | Uggla: no, you have to bother me as otherwise there will always be a more important review to look at. unfortunately I don't have a single clear prio list to work by. So I'm in a mode of who shouts louder / what issue burns with with a bigger flame | 14:31 |
| Uggla | gibi, ok so I'll SHOUT OUT LOUD ! ;) | 14:32 |
| gibi | loud and repeated :D that is the way :D | 14:32 |
| *** blarnath is now known as d34dh0r53 | 14:58 | |
| opendevreview | ribaudr proposed openstack/nova-specs master: Re-propose "Allow Manila shares to be directly attached to an instance when using libvirt" for Bobcat https://review.opendev.org/c/openstack/nova-specs/+/876706 | 15:08 |
| opendevreview | Merged openstack/placement master: Update master for stable/2023.1 https://review.opendev.org/c/openstack/placement/+/875875 | 15:17 |
| opendevreview | Merged openstack/nova-specs master: Re-propose "Allow local scaphandre directory to be mapped to an instance using virtiofs" for Bobcat https://review.opendev.org/c/openstack/nova-specs/+/876707 | 15:18 |
| opendevreview | Elod Illes proposed openstack/nova master: [stable-only] Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/nova/+/876752 | 15:37 |
| opendevreview | Elod Illes proposed openstack/nova master: [stable-only] Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/nova/+/876754 | 15:38 |
| opendevreview | Elod Illes proposed openstack/nova stable/2023.1: [stable-only] Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/nova/+/876551 | 15:39 |
| opendevreview | Elod Illes proposed openstack/nova stable/2023.1: [stable-only] Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/nova/+/876552 | 15:39 |
| opendevreview | Elod Illes proposed openstack/nova stable/2023.1: [stable-only] Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/nova/+/876552 | 15:40 |
| *** efried1 is now known as efried | 15:40 | |
| opendevreview | Merged openstack/nova-specs master: Re-propose "Allow Manila shares to be directly attached to an instance when using libvirt" for Bobcat https://review.opendev.org/c/openstack/nova-specs/+/876706 | 15:44 |
| bauzas | folks, don't be afraid if you see nova slots in the PTG website, I just prebooked some of them but I could release a few after our nova meeting :) | 15:45 |
| * bauzas wanted to have the diablo room as a dedicace to his first release he started his OpenStack journey :) | 15:46 | |
| bauzas | short notice reminder : nova meeting in 5 mins | 15:55 |
| bauzas | during this meeting I'll ask your opinions about the timeslots for the next PTG, be prepared. | 15:55 |
| * bauzas doesn't want to doodle for such things | 15:55 | |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue Mar 7 16:00:11 2023 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| gibi | o/ | 16:00 |
| bauzas | hey folks, welcome in the nova meeting | 16:00 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:00 |
| bauzas | ok, guess people will join softly, let's start | 16:01 |
| elodilles | o/ | 16:01 |
| bauzas | #topic Bugs (stuck/critical) | 16:01 |
| bauzas | #info No Critical bug | 16:01 |
| bauzas | (which is always good during a RC period) | 16:01 |
| Uggla | o/ | 16:01 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 14 new untriaged bugs (-3 since the last meeting) | 16:01 |
| bauzas | kudos to sean-k-mooney for the triage work, despite all the workload he already had | 16:02 |
| bauzas | pretty impressive | 16:02 |
| bauzas | sean-k-mooney: anything you wanna share to the team ? | 16:02 |
| gibi | (many things happens in parallel real time) | 16:03 |
| bauzas | ah, auniyal also helped, I see, we have two (optional, as always) triage etherpads this week | 16:03 |
| bauzas | #link https://etherpad.opendev.org/p/nova-bug-triage-20230301 | 16:03 |
| bauzas | #link https://etherpad.opendev.org/p/nova-bug-triage-20230306 | 16:03 |
| bauzas | gibi: I wish I would have an internal semaphore more than equals to 2 | 16:04 |
| bauzas | even 2 is hard for me to handle | 16:04 |
| bauzas | anyway | 16:04 |
| sean-k-mooney | i think i mentioned the main too downstream | 16:05 |
| sean-k-mooney | we broke windows + amd in zed | 16:05 |
| bauzas | sean-k-mooney wrote something about https://bugs.launchpad.net/nova/+bug/2009280 | 16:05 |
| sean-k-mooney | we should fix that and there is a mig issue | 16:05 |
| sean-k-mooney | those are the two highlights | 16:05 |
| sean-k-mooney | https://bugs.launchpad.net/nova/+bug/2009280 im in two mind about how to fix | 16:06 |
| bauzas | #link https://bugs.launchpad.net/nova/+bug/2009280 AMD-based computes may have a problem with Zed | 16:06 |
| sean-k-mooney | we can turn that off entirly or selectivly for amd hosts | 16:06 |
| bauzas | sean-k-mooney: given we merged the enlightments in Zed, this is unfortunately not a RC candidate :( | 16:06 |
| sean-k-mooney | i think turning off hv-evmc for everythign it the better option for backporting | 16:06 |
| sean-k-mooney | correct | 16:06 |
| sean-k-mooney | just a normal bug | 16:07 |
| sean-k-mooney | we can adress it and backprot after the offical relase is done | 16:07 |
| bauzas | sean-k-mooney: I agree, disabling the whole feature seems to me easier and less errorprone | 16:07 |
| bauzas | sean-k-mooney: putting the bug importance as High | 16:07 |
| bauzas | it's basically blocking a nova boot on windows images if AMD-based | 16:07 |
| sean-k-mooney | ack | 16:08 |
| bauzas | that's quite a large impact | 16:08 |
| sean-k-mooney | if you set the image property | 16:08 |
| sean-k-mooney | but i was debating between medium and high so im ok with high | 16:08 |
| bauzas | true, but how many production-level clouds are not setting the property ? :) | 16:08 |
| bauzas | note : it was an open question :d | 16:08 |
| sean-k-mooney | hehe i dont know but i think in either case we shoudl fix and backport it sonner rather then later | 16:09 |
| sean-k-mooney | i might try and write a ptch for it but if other want to go ahead | 16:09 |
| sean-k-mooney | i think we can move on for today | 16:10 |
| bauzas | cool | 16:10 |
| bauzas | and thanks | 16:10 |
| bauzas | for the MIG bug, let's discuss this off the meeting, but upstream support on nvidia is very limited | 16:10 |
| bauzas | unless the bug is reproducable on another hardware, I would tend to mark it Invalid either way | 16:11 |
| sean-k-mooney | ya it borderlien a feature but i think it need some discussion outside the meeting | 16:11 |
| bauzas | cool, I don't disagree | 16:11 |
| bauzas | moving on | 16:11 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:11 |
| bauzas | elodilles: well, this is your turn this week | 16:11 |
| elodilles | bauzas: ack | 16:11 |
| bauzas | how do you feel with all the releases patches coming up ? | 16:11 |
| bauzas | + the reno ugly bug | 16:12 |
| elodilles | bauzas: let's not postpone it now, i'll take the baton | 16:12 |
| bauzas | (well, technically not a bug, but rather an unexpected lack of support) | 16:12 |
| bauzas | cool cool | 16:12 |
| bauzas | and thanks | 16:12 |
| bauzas | elodilles: don't feel pressured | 16:12 |
| bauzas | #info bug baton is being passed to elodilles | 16:12 |
| bauzas | next topic | 16:12 |
| bauzas | #topic Gate status | 16:13 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:13 |
| bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures | 16:13 |
| bauzas | so, we have less oom issues, which is good | 16:13 |
| bauzas | mysql is less a noisy neighbor | 16:13 |
| bauzas | but we only touched a few jobs | 16:13 |
| bauzas | if you see other jobs that oom-kill mysql but nova-next and nova-ceph-multistore, let us know | 16:15 |
| bauzas | apart from that, I've seen other failures, but I hadn't a lot of time of digging | 16:15 |
| bauzas | unless anyone wants to address a specific failure, we may need to move on | 16:16 |
| bauzas | looks so | 16:16 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | 16:16 |
| bauzas | so we had periodic tempest-integrated-placement on stable/yoga that timed out | 16:17 |
| bauzas | I checked the log and it was just a slow job run | 16:18 |
| bauzas | so hopefully things will order back at the next run | 16:18 |
| bauzas | (and zed and master runs are OK) | 16:18 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:18 |
| bauzas | #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures | 16:19 |
| bauzas | #topic Release Planning | 16:19 |
| bauzas | #link https://releases.openstack.org/antelope/schedule.html | 16:19 |
| bauzas | #info Antelope-rc1 was this Monday | 16:19 |
| bauzas | so, we're now in a duplicity period, where we are both on Bobcat and Antelope timeframes :) | 16:19 |
| bauzas | if you've seen Tenet, you got it | 16:20 |
| bauzas | (the movie) | 16:20 |
| bauzas | now, we have a 2023.1 branch | 16:20 |
| elodilles | ~o~ | 16:20 |
| bauzas | #info as a reminder, no backports are possible on the 2023.1 branch *unless* they are regression bugfixes | 16:20 |
| bauzas | and accordingly all stable branches go on a quiet period since they're now dependent on the antelope branch | 16:21 |
| bauzas | #link https://etherpad.opendev.org/p/nova-antelope-rc-potential | 16:22 |
| bauzas | fwiw, our release notes are currently broken to be shown | 16:22 |
| bauzas | for Antelope | 16:22 |
| sean-k-mooney | we can still merge exsting backport but noting to 2023.1 | 16:23 |
| bauzas | context : https://review.opendev.org/c/openstack/nova/+/876553 | 16:23 |
| sean-k-mooney | that is not for an rc | 16:23 |
| bauzas | sean-k-mooney: well, if the original patch is on Antelope, sure | 16:23 |
| sean-k-mooney | we have plent of open backport on exsting stable branch that coudl use review | 16:24 |
| bauzas | elodilles: iiuc, we'll need to enable the new reno ordering in our releasenotes ? | 16:24 |
| bauzas | once the reno patch got landed | 16:24 |
| elodilles | bauzas: fyi, reno workaround has landed, but not yet released | 16:24 |
| bauzas | oh, missed that | 16:24 |
| elodilles | bauzas: and we don't need to do anything, but use the new reno release | 16:25 |
| bauzas | sean-k-mooney: yup, don't disagree | 16:25 |
| sean-k-mooney | do we need to do any changes once its released | 16:25 |
| sean-k-mooney | or will the release notes get rebuilt automatically | 16:25 |
| bauzas | elodilles: ah, right, so dhellmann's proposition was accepted | 16:25 |
| sean-k-mooney | ok cool | 16:25 |
| sean-k-mooney | if we dont need to do anything great | 16:25 |
| bauzas | sean-k-mooney: yeah, so there was a patch up for opting-in to the new reno ordering | 16:25 |
| sean-k-mooney | by use the new reno does that mean increase the min version in requirements | 16:26 |
| bauzas | but doug said he was ok with having it by default | 16:26 |
| sean-k-mooney | or just realy on upper-constratis | 16:26 |
| bauzas | sean-k-mooney: reno isn't part of our requirements | 16:26 |
| bauzas | (unless I'm wrong) | 16:26 |
| sean-k-mooney | its in our doc requirements i think | 16:26 |
| bauzas | that's a specific target, which isn't docs | 16:26 |
| elodilles | actually, it is part of upper-constraints | 16:26 |
| sean-k-mooney | https://github.com/openstack/nova/blob/master/doc/requirements.txt#L13 | 16:26 |
| bauzas | https://github.com/openstack/nova/blob/master/tox.ini#L238 | 16:27 |
| elodilles | but for master branch (bobcat) I think it will be soon possible to bump | 16:27 |
| sean-k-mooney | https://github.com/openstack/nova/blob/master/tox.ini#L238-L242 | 16:27 |
| sean-k-mooney | the release notes use the docs requirements file | 16:27 |
| bauzas | sean-k-mooney: snap | 16:27 |
| sean-k-mooney | so ya it will automatically get picked up from uc | 16:28 |
| sean-k-mooney | but im wonderign if we want to block the older releases or not | 16:28 |
| sean-k-mooney | we dont have too but we could | 16:28 |
| bauzas | it's backwards-compatible | 16:28 |
| bauzas | so I don't think we need | 16:28 |
| sean-k-mooney | yep i was more thinking of a signal to packages | 16:28 |
| sean-k-mooney | but im fine with not bumping the min version | 16:29 |
| bauzas | elodilles: the new reno release is a x. version ? | 16:29 |
| bauzas | or a .y ? | 16:29 |
| sean-k-mooney | all of the offical release notes will be update proeprly | 16:29 |
| elodilles | it will be a MAJOR version bump | 16:29 |
| bauzas | cool, so x. | 16:29 |
| elodilles | yepp | 16:29 |
| bauzas | sean-k-mooney: well technically, our master branch will need this | 16:30 |
| sean-k-mooney | yep we would merge it in master and backprot to 2023.1 | 16:30 |
| bauzas | maybe the 2023.1 branch will need it too | 16:30 |
| sean-k-mooney | reno>=4.0.0 | 16:30 |
| bauzas | but for other branches, they shouldn't mention the antelope notes | 16:30 |
| sean-k-mooney | correct | 16:30 |
| sean-k-mooney | we cant bump the requirement on older banches anyway | 16:31 |
| bauzas | sean-k-mooney: the patch in question is https://review.opendev.org/c/openstack/nova/+/876553 | 16:31 |
| sean-k-mooney | we only have the opertunity to do it on 2023.1 because we have not releassed yet | 16:31 |
| bauzas | yes | 16:31 |
| bauzas | and we'll need it once we tag | 16:31 |
| bauzas | a stable antelope release, I mean | 16:32 |
| bauzas | oh wait no | 16:32 |
| bauzas | maybe it's unnecessaru | 16:32 |
| bauzas | our gits tags will mention the project tags, not the openstack release | 16:32 |
| bauzas | the problem with reno is about the branches ordering | 16:32 |
| bauzas | anyway, we'll figure that out | 16:33 |
| bauzas | no need to spec it up too | 16:33 |
| bauzas | here | 16:33 |
| bauzas | we also need to merge https://review.opendev.org/c/openstack/nova/+/875621/ but I need to respin it | 16:33 |
| sean-k-mooney | reno also supprots metadata in the commit log to denote a release | 16:34 |
| sean-k-mooney | so that might also help | 16:34 |
| sean-k-mooney | but ya we can proably move on | 16:34 |
| sean-k-mooney | we willl figure this out | 16:34 |
| bauzas | last but not the least (rc1 is a busy time for a PTL), I did a bit of launchpad scrubbing | 16:34 |
| bauzas | #info https://blueprints.launchpad.net/nova/antelope now shows 'deferred' for approved but non-implemented Blueprints | 16:35 |
| bauzas | the 2023.2 specs directory is open and I already fast-approved two specs that were accepted in Antelope | 16:35 |
| * sean-k-mooney clicks | 16:35 | |
| bauzas | I'll add the launchpad bobcat series after the meeting so technically, we can now start to approve new specs and specless blueprints | 16:36 |
| sean-k-mooney | ack | 16:36 |
| sean-k-mooney | we should start using the placement repo for placement thigns now too | 16:36 |
| bauzas | that's it for this topic (larger than usual) | 16:36 |
| sean-k-mooney | were started to do that partly last cycle but not consitently | 16:36 |
| bauzas | sean-k-mooney: placement will also have its own launchpad bobcat series | 16:36 |
| sean-k-mooney | yes | 16:37 |
| bauzas | and yeah, we have to mimic the same than nova | 16:37 |
| bauzas | as we agreed on stopping to use Storyboard | 16:37 |
| sean-k-mooney | but we used a mix of stories and task instory board and some lanchpad stuff | 16:37 |
| sean-k-mooney | so lets try and just use lanuchpad this time | 16:37 |
| bauzas | that's a good point, I should somehow signal in Storyboard that we no longer support it for Placezment | 16:37 |
| sean-k-mooney | ideally we should see if we can make it readonly and/or clsoe the exiting issues | 16:38 |
| bauzas | #action bauzas to clean-up the stories in Storyboard and tell their owners to recreate a Launchpad bug or blueprint if they wish to carry it on | 16:38 |
| bauzas | moving on | 16:39 |
| bauzas | #info Uggla and auniyal are the new release liaisons https://review.opendev.org/c/openstack/releases/+/876758 | 16:39 |
| elodilles | \o/ | 16:39 |
| * bauzas just hopes the releases team catches this patch :) | 16:39 | |
| bauzas | elodilles: don't feel overlooked :p | 16:39 |
| elodilles | :] | 16:39 |
| elodilles | i won't :) | 16:40 |
| auniyal | we need to update the bug tracker link here https://opendev.org/openstack/placement | 16:40 |
| bauzas | auniyal: excellent point, fancy creating a change against it ? | 16:40 |
| auniyal | yes | 16:40 |
| sean-k-mooney | i belvie that is in the governance repo | 16:40 |
| bauzas | cool, thanks | 16:40 |
| sean-k-mooney | posibly the main config repo | 16:41 |
| bauzas | sean-k-mooney: I'm pretty it isn't | 16:41 |
| bauzas | sure* | 16:41 |
| bauzas | I've recently seen the project yaml files and I don't remember any mention of the bug tracking system | 16:41 |
| bauzas | but I could have missed it | 16:41 |
| bauzas | anyway, action is on me | 16:42 |
| bauzas | next topic, and I'd like to see some quorum on it | 16:42 |
| bauzas | #topic vPTG Planning | 16:42 |
| bauzas | the usual reminder : | 16:42 |
| bauzas | #link https://www.eventbrite.com/e/project-teams-gathering-march-2023-tickets-483971570997 Register your free ticket | 16:42 |
| bauzas | even if this is a free event, it helps the foundation folks to correctly identify the attendance | 16:43 |
| bauzas | #link https://etherpad.opendev.org/p/nova-bobcat-ptg Draft PTG etherpad | 16:43 |
| bauzas | #info we need to agree on the agenda and how many slots we book | 16:43 |
| bauzas | the ptg website is up | 16:43 |
| bauzas | #link https://ptg.opendev.org/ptg.html | 16:44 |
| bauzas | as you see, I've booked four hour slots per day between Tues and Friday | 16:44 |
| bauzas | this is quite a large time, but I don't want to consume all of them | 16:44 |
| bauzas | anyone having other opinions on the strawman proposal of 4x 4 hours ? | 16:45 |
| bauzas | this would be 13:00-17:00 UTC | 16:45 |
| bauzas | ideally, I'd also want to attend the TC sessions so I may require some co-chair if it conflicts | 16:46 |
| bauzas | again, anyone having concerns with this proposal ? | 16:47 |
| sean-k-mooney | no concerns really i assume we will subdevide the 4 hour into 4 50min slots and 10 min breaks | 16:47 |
| bauzas | that's heard and agreed | 16:48 |
| bauzas | I'm not a fan of long running days | 16:48 |
| bauzas | this is exhausting at most. | 16:48 |
| bauzas | I was somehow hoping the PTG could turn into some physical event before I stop running as a PTL, but I was wrong and I need to support it | 16:49 |
| bauzas | and I think we'll possibly never return to a twice-a-year physical design event, so the ship has sailed and we need to get used to it | 16:49 |
| bauzas | zoom FTW, yay. | 16:50 |
| bauzas | anyway, I don't hear strong objections and the schedule is flexible | 16:50 |
| bauzas | we can modify that later if we wish | 16:50 |
| bauzas | this is just a matter of booking or unbooking a timeslot | 16:51 |
| bauzas | moving on then | 16:51 |
| bauzas | #action bauzas to notify the nova community by a ML thread of the proposed agenda for Nova sessions | 16:51 |
| bauzas | again, as a reminder, don't forgot to add your PTG topics in advance | 16:52 |
| bauzas | #topic Review priorities | 16:52 |
| bauzas | #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) | 16:52 |
| bauzas | moving on | 16:52 |
| bauzas | #info As a reminder, cores eager to review changes can +1 to indicate their interest, +2 for committing to the review | 16:53 |
| bauzas | #topic Stable Branches | 16:53 |
| bauzas | elodilles: you have a quick time | 16:53 |
| elodilles | ack | 16:53 |
| elodilles | start with some repetition | 16:53 |
| elodilles | #info stable/2023.1 branches were cut | 16:53 |
| elodilles | #info stable gates seem to be OK - though it's hard to merge patches due to intermittent failures | 16:53 |
| bauzas | unfortunately true | 16:53 |
| elodilles | on older branches especially | 16:53 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:53 |
| elodilles | and that's all | 16:54 |
| elodilles | to be quick | 16:54 |
| bauzas | thanks a lot | 16:54 |
| bauzas | last topic | 16:54 |
| bauzas | #topic Open discussion | 16:54 |
| bauzas | we have an item | 16:54 |
| bauzas | (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. | 16:54 |
| bauzas | tl;dr: answer is yes, this is expected behaviour | 16:55 |
| bauzas | our release notes tooling provides a list of items based on YAML files that exist on a git branch | 16:55 |
| bauzas | and accordingly heavily relies on git for the ordering and sorting | 16:56 |
| astupnik | ack. I am wondering what's the best approach for tracking known issues? | 16:56 |
| bauzas | known issues that aren't fixed ? | 16:56 |
| sean-k-mooney | we dont really want to retoactivly delete the old release notes for knwon issues | 16:56 |
| bauzas | that's a very good question and I don't have an existing solution on top of my head | 16:56 |
| sean-k-mooney | we generally try ot refence the previous know issue in the patch that fixes it | 16:56 |
| sean-k-mooney | and update the docs where approprate | 16:57 |
| astupnik | the problem is that known issues in release notes only contain new issues, not ones that existed before release... | 16:57 |
| sean-k-mooney | correct that is waht we wanted | 16:57 |
| astupnik | ack | 16:57 |
| bauzas | well, you have a list of known issues per release here https://docs.openstack.org/releasenotes/nova/zed.html | 16:57 |
| bauzas | and others | 16:57 |
| sean-k-mooney | we also tend to do thins like this https://docs.openstack.org/nova/latest/admin/virtual-gpu.html#caveats | 16:58 |
| bauzas | but we don't have a specific page that references a list of known issues over all the releases, despite that being possible with the reno tool, I think | 16:58 |
| sean-k-mooney | i dont know how we would mark them as resolved | 16:59 |
| bauzas | the best remains to bug the worldwide intelligence that stays on that channel :) | 16:59 |
| sean-k-mooney | you dont really want a list of all know issue ever just the ones that are still outstanding | 16:59 |
| astupnik | thank you for clarifications. Simplest way I found is to look for "issue" in release notes folder. I was wondering if there is more user-friendly option. | 16:59 |
| bauzas | sean-k-mooney: yeah tracking is a problem | 16:59 |
| sean-k-mooney | im sure chatgpt can fix this for us :P | 16:59 |
| bauzas | ideally a known issue should mention a bug report | 16:59 |
| astupnik | sean-k-mooney: I want all unresolved issues | 16:59 |
| sean-k-mooney | that is our launchpad open bug list | 17:00 |
| astupnik | heh, ok | 17:00 |
| bauzas | so people should know the status of that issue by querying the bug tracker | 17:00 |
| bauzas | sean-k-mooney: on a side note, I have a PTG topic on it :) | 17:00 |
| sean-k-mooney | ack | 17:00 |
| bauzas | -ETOOMANY open bugs | 17:00 |
| bauzas | let's just axe them ::) | 17:00 |
| *** artom_ is now known as artom | 17:01 | |
| bauzas | anyway, we're overtime | 17:01 |
| bauzas | thanks all | 17:01 |
| bauzas | #endmeeting | 17:01 |
| opendevmeet | Meeting ended Tue Mar 7 17:01:10 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:01 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-03-07-16.00.html | 17:01 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-03-07-16.00.txt | 17:01 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-03-07-16.00.log.html | 17:01 |
| elodilles | thanks o/ | 17:01 |
| opendevreview | Amit Uniyal proposed openstack/placement master: Bugtracker link update https://review.opendev.org/c/openstack/placement/+/876768 | 17:03 |
| sean-k-mooney | bauzas: im conflicted about https://review.opendev.org/c/openstack/nova/+/875621 by the way | 17:26 |
| sean-k-mooney | you should not need to delete those test but we might need to modify them slightly | 17:27 |
| sean-k-mooney | at some point we can drop the version check in the api and the tests | 17:27 |
| sean-k-mooney | perhaps for now we should set https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.disable_compute_service_check_for_ffu | 17:27 |
| sean-k-mooney | in them | 17:27 |
| sean-k-mooney | to disable the compute service verion check | 17:28 |
| dansmith | I'm confused | 17:32 |
| dansmith | I thought we were going to set the min version for bobcat to zed to keep testing N-2 to master | 17:32 |
| dansmith | oh wait, I'm being stupid | 17:32 |
| dansmith | no wait | 17:32 |
| bauzas | sean-k-mooney: yeah I'll try to modify the tests | 17:34 |
| dansmith | yeah, that workaround is the thing we need to support N-2 to N upgrades without being live, so the conductors start before the computes have come online and upgraded, right? | 17:34 |
| dansmith | and we're setting this in the skip-level job already IIRC | 17:34 |
| bauzas | dansmith: the problem is that the test verifies some Yoga compute | 17:34 |
| dansmith | the vdpa test? | 17:34 |
| bauzas | so, even if we were saying ok for having N-2 computes, those tests couldn't work | 17:35 |
| bauzas | dansmith: yea | 17:35 |
| dansmith | okay, that just means our functional tests are broken, not the grenade job right? | 17:35 |
| opendevreview | Amit Uniyal proposed openstack/placement master: Bugtracker link update https://review.opendev.org/c/openstack/placement/+/876768 | 17:36 |
| bauzas | dansmith: yeah | 17:36 |
| dansmith | I guess I'm jumped over that in my head and thought there was a suggestions that the grenade job had a problem | 17:36 |
| dansmith | gotcha, nevermind me :) | 17:36 |
| bauzas | context : https://fb9f1a762c721749bb72-4adf110539aed9252479dc6b548d2884.ssl.cf5.rackcdn.com/875621/9/check/nova-tox-functional-py38/7df3e76/testr_results.htm | 17:36 |
| dansmith | yeah | 17:36 |
| bauzas | so I'll try to modify those functional tests | 17:36 |
| dansmith | yup | 17:36 |
| dansmith | I'm caught up now :) | 17:37 |
| bauzas | either I'll delete those tests given we no longer need to verify yoga computes | 17:37 |
| bauzas | or I'll find a way to verify yoga computes with antelope services | 17:37 |
| dansmith | I think we have other tests that continue to test those things | 17:38 |
| dansmith | but also, if we're past the support envelope for those things, I'm not sure we need the tests or the code that supports them | 17:38 |
| dansmith | if it's really RPC compat then sure, but if it's service version based, maybe not | 17:39 |
| bauzas | dansmith: in general we have unittests verifying RPC compatibilty | 17:42 |
| bauzas | like, we have UTs for RPC 6.x compute versions | 17:42 |
| bauzas | that continue to verify if we can call a 5.x one | 17:43 |
| dansmith | right, what I'm saying is.. if the functionality being tested is that service version X can coexist with master, we should be able to drop those tests *and* the functionality once X becomes old enough | 17:43 |
| bauzas | dansmith: yeah me too | 17:43 |
| bauzas | hence me saying I'll try to see if we can modify the tests, but if not, I'll delete those tests as we no longer support Yoga computes in Bobcat | 17:44 |
| bauzas | sean-k-mooney: ^ | 17:44 |
| bauzas | dansmith: btw. should I modify my change to rather depend on https://review.opendev.org/c/openstack/nova/+/875773 ? | 17:46 |
| bauzas | and no longer modify zuul to say voting for grenade-skip-level https://review.opendev.org/c/openstack/nova/+/875621/9/.zuul.yaml | 17:46 |
| dansmith | I mean it's up to you.. depends on how much of a hurry you're in I guess | 17:47 |
| bauzas | dansmith: well, here I need your advice | 17:48 |
| bauzas | we'll now have two zuul jobs | 17:48 |
| bauzas | grenade-skip-level and grenade-skip-level-always | 17:48 |
| bauzas | none of them will be voting once we merge https://review.opendev.org/c/openstack/nova/+/875773 | 17:49 |
| bauzas | my point is, should we get one of them voting and if so, which one ? | 17:49 |
| bauzas | in a non-SLURP release I mean | 17:49 |
| dansmith | we should get the always job voting on bobcat | 17:49 |
| dansmith | are we ready to merge that job change now, or are we waiting still? | 17:50 |
| bauzas | dansmith: if so, I'll rebase my change on top of yours | 17:50 |
| dansmith | if we're ready, then I say depends-on my change and make always voting | 17:50 |
| bauzas | and change zuul to make the -always voting | 17:50 |
| bauzas | cool | 17:50 |
| dansmith | I think that's just waiting on grenade and devstack branching 2023.1, which usually happens a bit after the other projects, IIRC | 17:51 |
| dansmith | gmann: ^ | 17:51 |
| bauzas | dansmith: and then, once we open C, we enable grenade-skip-level job and make it voting too, amirite ? | 17:51 |
| dansmith | the always job will work for C as well | 17:52 |
| dansmith | or are you asking how to avoid running both? | 17:52 |
| bauzas | no, I want to make sure I understand you | 17:52 |
| bauzas | https://review.opendev.org/c/openstack/grenade/+/875990/2/.zuul.yaml | 17:52 |
| bauzas | in there, that means we'll have a -always job that always test N-2 | 17:53 |
| bauzas | and a specific grenade-skip-level job that tests the previous SLURP release (or yoga in our case) | 17:53 |
| dansmith | right, which for a slurp release will be the same for both jobs | 17:53 |
| bauzas | correct | 17:53 |
| bauzas | but that doesn't tell what a project should be testing | 17:53 |
| bauzas | when we have a slurp release | 17:54 |
| bauzas | the -always will always run and voting, as its name says :) | 17:54 |
| bauzas | but at the beginning of C, we would then enable the grenade-skip-level job and make it voting too, then ? | 17:54 |
| dansmith | no, because it would be the exact same as the -always job in C | 17:54 |
| dansmith | there's no reason to run both | 17:55 |
| bauzas | so we would just change zuul to use grenade-skip-level instead of -always ? | 17:55 |
| bauzas | or not changing anything ? :) | 17:55 |
| dansmith | I don't know how we could avoid inheriting the regular job from the template, but we can worry about that when C comes, IMHO | 17:55 |
| bauzas | meh ok | 17:55 |
| dansmith | we could just remove the -always job in the slurp releases since we will get the regular job automatically, but I'd prefer to avoid that, I just don't know the zuul-fu to make that happen, but it's a problem for later, IMHO :) | 17:56 |
| bauzas | honestly, if you want MHO, now that we have an -always job that tests N-2 even on non-SLURP, I'm quite intended to leave it as it is, whether it's a slurp or not in the master branch :) | 17:56 |
| dansmith | that's what I'm trying to say | 17:56 |
| bauzas | and just pretend the grenade-skip-level job never existed :) | 17:56 |
| dansmith | right, that's what we should do | 17:57 |
| bauzas | cool, then I understand it better :) | 17:57 |
| dansmith | I guess the skip-level job is not in the template, actually | 17:57 |
| dansmith | I was thinking we'd inherit that from the template regardless, but we won't | 17:57 |
| dansmith | so yes, all we need to do is enable -always and voting=true and we're good forever | 17:58 |
| bauzas | all good | 17:58 |
| bauzas | wfm | 17:58 |
| *** efried1 is now known as efried | 18:03 | |
| bauzas | gmann: now we branched 2023.1, do you want to explicitly mark the branches on https://review.opendev.org/c/openstack/nova/+/875773 ? | 18:09 |
| * bauzas stops to work for the day, seeya | 18:34 | |
| gmann | bauzas: no that is not needed as it is defined as '-always' now so we will open this to run on everywhere it is added. for example once we will have stable/2023.2 it will continue running there to rest stable/zed->stable/2023.2 | 18:41 |
| gmann | and setting of those and on future master will be taken care on grenade side | 18:42 |
| gmann | dansmith: you mean grenade-skip-level-always to be always run and only skip level job we will have and if project want they can stop it to run on non-slurp they can do. That way grenade-skip-level will disappear ? | 18:46 |
| dansmith | gmann: no I think if the project only wants to test skip-level on slurps, they use skip-level, if they want to always test N-2->master, they use skip-level-always | 18:47 |
| gmann | and we can add grenade-skip-level-always in integrated gate as voting in SLURP release only | 18:47 |
| gmann | dansmith: in SLURP grenade-skip-level and grenade-skip-level-always will be with same setting so why we cannot just keep grenade-skip-level-alwaysonly | 18:48 |
| gmann | and remove grenade-skip-level completly | 18:48 |
| gmann | I mean grenade-skip-level-always always do N-2 -> N upgrade and 1. project need to run it mandatory in SLURP 2. it is optional to run in non-SLURP | 18:48 |
| dansmith | you mean have the job branch-limited in the template and make nova override branches to be "all" for that job? | 18:48 |
| gmann | nova having it in check pipeline should run even integrated template does add it but this is something we can test as zuul crazy magic | 18:49 |
| gmann | but idea is to handle 1.mandatory in SLURP 2. optional in non-SLURP can by handled via branch variant | 18:50 |
| gmann | keeping both jobs will confuse people | 18:50 |
| gmann | let me do and show the template and greande side changes once we will branch greande (maybe this or early next week) and we can see/test how that can work for both cases 1. project want to run it in non-SLURP 2. project do not | 18:54 |
| *** efried1 is now known as efried | 19:21 | |
| opendevreview | David Hill proposed openstack/nova master: Wait for VM to be paused before cleaning up https://review.opendev.org/c/openstack/nova/+/876776 | 19:22 |
| artom | gmann, oh hey, seeing your name here reminds me to gently poke you for input on https://review.opendev.org/c/openstack/nova/+/875653 | 19:25 |
| gmann | artom: yeah I opened it few days back after seeing it from channel and it is in my list. I will try to do it today if not tomorrow for sure. | 19:28 |
| gmann | thanks for ping | 19:28 |
| artom | No huge rush, good to know you're aware :) | 19:29 |
| *** efried1 is now known as efried | 19:47 | |
| *** efried1 is now known as efried | 22:05 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!