16:00:12 <bauzas> #startmeeting nova
16:00:12 <opendevmeet> Meeting started Tue May 10 16:00:12 2022 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:12 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:12 <opendevmeet> The meeting name has been set to 'nova'
16:00:19 <bauzas> hello everyone
16:00:21 <stephenfin> o/
16:00:22 <elodilles> o/
16:00:39 <bauzas> #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
16:00:53 <chateaulav> \0
16:01:50 <bauzas> ok, let's start, people can join
16:01:54 <bauzas> #topic Bugs (stuck/critical)
16:02:00 <bauzas> #info No Critical bug
16:02:06 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 19 new untriaged bugs (-3 since the last meeting)
16:02:14 <bauzas> thanks artom et al. for the triage
16:02:35 <artom> \o/ a net minus!
16:02:40 <bauzas> artom created an etherpad for bugs he looks https://etherpad.opendev.org/p/nova-bug-triage-20220503
16:02:44 <bauzas> looked*
16:03:03 <bauzas> artom: nothing to tell about those ?
16:03:19 <artom> Not really, just the evacuation one that's really funky
16:03:31 <artom> gibi and sean-k-mooney already looked at the reproducer func test
16:03:33 <bauzas> okay thanks
16:03:51 <bauzas> continuing then
16:03:59 <sean-k-mooney> because it inovled data loss im oke with it being a bug
16:04:05 <bauzas> #link https://storyboard.openstack.org/#!/project/openstack/placement 26 open stories (0 since the last meeting) in Storyboard for Placement
16:04:10 <sean-k-mooney> but otherwise i woudl consider it a small specless blueprint
16:04:24 <bauzas> sean-k-mooney: artom: bug link ?
16:04:46 <sean-k-mooney> https://review.opendev.org/c/openstack/nova/+/841170
16:04:54 <sean-k-mooney> https://bugs.launchpad.net/nova/+bug/1952745
16:05:35 <bauzas> thanks
16:07:08 <bauzas> ok, don't want to overdiscuss this bug in large, so I trust you, folks
16:07:36 <bauzas> let's say Valid and we can nitpick on whether it's requiring a BP or not during the code review
16:07:55 <sean-k-mooney> i think we can proceed as a bug
16:08:13 <sean-k-mooney> but its borderline
16:08:20 <sean-k-mooney> so we can move on i think
16:08:40 <bauzas> my first thoughts wonder whether this should be supported or not
16:08:48 <bauzas> but I need to look at other comments
16:09:09 <bauzas> but I agree, evacuate should work even if the compute is definitely gone
16:09:26 <bauzas> that's actually why we have evacuate :)
16:09:51 <bauzas> but let's not bikeshid this by noxw
16:09:55 <bauzas> next point
16:10:03 <bauzas> #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:10:15 <kashyap> bauzas: On bugs ...
16:10:22 <bauzas> which leads me to the next point,
16:10:27 <bauzas> #info Next bug baton is passed to Uggla
16:10:38 <bauzas> Uggla: you're ok with this ?
16:10:58 <bauzas> reminder : this is best-effort
16:11:18 <bauzas> metrics are cool, but that's not important
16:11:25 <bauzas> any effort counts, even the lowest
16:11:44 <kashyap> Having dedicated days of public bug triage would be nice.  We did it in the distant past (here and also for RDO)
16:11:48 <bauzas> hmmmm, looks like Uggla is gone for today
16:11:54 <kashyap> But doing it off alone quietly ... it's hard to sustain
16:12:15 <sean-k-mooney> kashyap: i think that is the reason to have it rotate
16:12:23 <bauzas> kashyap: we can discuss the opportunity of a Bug Triage day later if you wish
16:12:38 <bauzas> but this is exceptional by nature
16:12:42 * artom did it yesterday afternoon
16:12:52 <bauzas> rotation helps with the triage fatigue
16:13:00 <kashyap> Right.  A small idea:
16:13:20 <kashyap> When we were bootstrapping the RDO community, I used to do these public reports to the mailing list:
16:13:23 <kashyap> https://kashyapc.fedorapeople.org/virt/openstack//rdo-bug-status/2017/nova-bugs-05-SEP-2017.txt
16:13:23 <bauzas> I don't want people to mark their agendas with a triage day, we're upstream here and I don't want to order people
16:13:42 <kashyap> _With_ the title of the bug in the mail; so people could skim it via email ...
16:14:16 <kashyap> (I'm not sure if that'll work here, to send them to the -discuss list.  Once every month?  I don't know)
16:14:26 <kashyap> bauzas: No, you're misunderstanding me :)
16:14:27 <bauzas> kashyap: again I don't want to force any formalization of things
16:14:33 <kashyap> bauzas: We're not "ordering" anyoone on anything.
16:14:46 <sean-k-mooney> that feels a bit heavy wait but proably workable i would be less enclined to do it if i had to send a main however
16:14:57 <kashyap> bauzas: We've done this countless times before when doing upstream RDO community work:
16:15:11 <bauzas> sean-k-mooney: even the triage etherpad has to be kept *optional*
16:15:26 <kashyap> You simply mark a day ahead of time, note it on the list, as an announce to let people know.  If people have time, thye'll join
16:15:31 <bauzas> this is nice artom, melwitt and gibi created one
16:15:41 <bauzas> but this hasn't to be mandatory
16:15:41 <kashyap> bauzas: This is standard proceduce that's also done in much bigger communities like Fedora
16:15:56 <sean-k-mooney> ok take me off the triage list then
16:16:03 <sean-k-mooney> this is getting more compliated then i want
16:16:12 <bauzas> sean-k-mooney: again, no, I want to keep it simple
16:16:19 <bauzas> no triage etherpad, no mailing lists
16:16:42 <kashyap> Sure, I know people also have lesser "will power", with shorter teams and bandwidth.
16:16:44 <sean-k-mooney> ack i was happen to skim hte new bugs a few time a week during my week
16:16:50 <kashyap> bauzas: That's fine, we can actually move on.
16:17:02 <sean-k-mooney> but dont really want to have to add more paperwork
16:17:19 <bauzas> sean-k-mooney: I'm fully on the same page, see my previous comments
16:17:28 <kashyap> bauzas: The mail list is an "announce".  People won't magically suddenly think: "Yay!  I'm going to dedicate this morning for bug triage"
16:17:37 <kashyap> It's a rare thing unless one has a habit, and good filters for it.
16:17:59 <bauzas> kashyap: about the mailing-list reminder email once per month, that's maybe something a PTL *could* do
16:18:04 <kashyap> sean-k-mooney: Sure, I'm the last one to suggest adding "paperwork" (yikes)
16:18:12 <Uggla> bauzas, sorry was out
16:18:24 <bauzas> kashyap: but I don't want to enforce any rules
16:18:28 <kashyap> sean-k-mooney: The point I'm making is: sharing experiences from other communities how public bug triage used to be sustained.
16:18:37 <kashyap> bauzas: Sigh, you keep saying that.  I'm saying to "enforce" any rules :)
16:18:48 <Uggla> bauzas, ok for the bug baton
16:18:51 <bauzas> kashyap: proposing to send an email is a rule :)
16:19:03 <kashyap> It's not; it's a suggestion.  "Proposal" != "rule"
16:20:00 <bauzas> kashyap: sorry about the confusion, I just wanted to explain the bug triage rotation upstream is necessarly something people opt-in on their free time with their own things
16:20:11 <kashyap> bauzas: We can move on; really.  I've done community bug triages with much larger groups in the past (Fedora test days, RDO, CentOS, etc).  Just sharing what worked.
16:20:21 <kashyap> (There isn't possibility, given the thinness of the community here.)
16:20:44 <kashyap> Of course, everything is "opt-in" upstream.
16:21:07 <bauzas> kashyap: noted, I just wanted to clarify that triage etherpads *are* optional
16:21:08 <kashyap> bauzas: (I missed a word earlier: I'm saying NOT to "enforce" any riles)
16:21:17 <kashyap> s/riles/rules/
16:22:04 <kashyap> Sure.  Just as a general point: in upstreams I never suggest anything as a "rule".  Everything _is_ optional.  As you can't "demand" community time.
16:22:48 <bauzas> kashyap: that's why emails are difficult, because operators and consumers of this perodic email are in demand with more
16:23:05 <bauzas> either the email is read and people ask for a new one
16:23:22 <bauzas> or the email isn't read and then the sake of sending such email is meaningless
16:23:54 <bauzas> that's why I can only propose myself to send such periodic emails
16:24:27 <kashyap> Sure.  It doesn't have to be.  We've tried everything in the past, "bug czars", etc.
16:24:52 <bauzas> ... with a short period of life :)
16:24:58 <bauzas> anyway, I guess we can move on
16:25:40 <bauzas> Uggla: thanks for offering your time, again, no rush
16:27:09 <bauzas> next topic
16:27:10 <bauzas> #topic Gate status
16:27:15 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:27:20 <bauzas> #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly Placement periodic job status
16:27:31 <bauzas> #link https://zuul.opendev.org/t/openstack/builds?job_name=nova-emulation&pipeline=periodic-weekly&skip=0 Emulation periodic job runs
16:27:55 <bauzas> things look good, AFAICS
16:28:14 <bauzas> we have tho a new gate bug https://bugs.launchpad.net/nova/+bug/1970642
16:28:51 <bauzas> nothing to tell tho
16:28:52 <bauzas> moving on
16:28:59 <bauzas> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:29:03 <bauzas> #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures
16:29:17 <bauzas> next topic,
16:29:22 <bauzas> #topic Release Planning
16:29:27 <bauzas> #link https://releases.openstack.org/zed/schedule.html
16:29:31 <bauzas> #info Zed-1 is due in 1 week
16:29:38 <bauzas> well, 9 days tbc
16:30:00 <bauzas> there is no deadline about this milestone in terms of code or spec review tbc
16:30:10 <bauzas> #info Spec review day happens today on May 10th
16:30:25 <bauzas> I've seen good efforts from a couple of people here
16:30:34 <sean-k-mooney> for m1 we should try and land any traits for approved specs
16:30:35 <bauzas> thanks to all who played this game today
16:30:46 <sean-k-mooney> so that they can be inlcuded in the m1 release
16:30:54 <bauzas> this will continue until end of our day, depending on your TZ of course :)
16:31:28 <bauzas> sean-k-mooney: good call
16:32:47 <bauzas> sean-k-mooney: I guess you meant https://review.opendev.org/c/openstack/osc-placement/+/828545 ?
16:34:12 <sean-k-mooney> no
16:34:29 <bauzas> link then ?
16:35:25 <sean-k-mooney> things like this https://review.opendev.org/c/openstack/os-traits/+/832769
16:35:36 <bauzas> oh
16:35:37 <sean-k-mooney> that is not appoved yet
16:35:52 <sean-k-mooney> but for our unit tests to pass traits need to be in a release version of os-traits
16:35:54 <bauzas> for the library release on zed-1, gotcha
16:36:04 <sean-k-mooney> yes
16:36:07 <bauzas> surely, we can make it
16:36:39 <bauzas> sean-k-mooney: let's coordinate tomorrow for some review effort on the libs changes then
16:36:51 <opendevreview> Artom Lifshitz proposed openstack/nova master: Reproduce bug 1952745  https://review.opendev.org/c/openstack/nova/+/841170
16:36:51 <opendevreview> Artom Lifshitz proposed openstack/nova master: Move evacuated instance destruction to new post_start_hook  https://review.opendev.org/c/openstack/nova/+/841308
16:37:10 <sean-k-mooney> sure its not the end of the world if we dont have them merge by m1
16:37:29 <sean-k-mooney> i just blocks us mergin the nova code until we do an os-triats release whihc is cheap
16:37:33 <bauzas> sean-k-mooney: the only problem with the change you just proposed is that it depends on a spec which hasn't been approved yet :)
16:37:47 <bauzas> sean-k-mooney: yup, we had that problem in the past
16:37:56 <sean-k-mooney> yep
16:38:14 <sean-k-mooney> so we may have approves specs today that added traits. not sure we did
16:38:21 <bauzas> maybe let's focus on reviewing specs that have library dependencies
16:38:44 <sean-k-mooney> jsut wanted to highlight for peopel if you own one fo those spec then please submit a os-tirat patch if it had traits and ill be happy to review
16:38:46 <bauzas> sean-k-mooney: no, but I can personnally focus my effort on such specs
16:38:58 <bauzas> moving on tho, time flies
16:39:04 <bauzas> #topic Review priorities
16:39:11 <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
16:39:15 <bauzas> #link https://review.opendev.org/c/openstack/project-config/+/837595 Gerrit policy for Review-prio contributors flag. Naming bikeshed in there.
16:39:22 <bauzas> #link https://docs.openstack.org/nova/latest/contributor/process.html#what-the-review-priority-label-in-gerrit-are-use-for Documentation we already have
16:39:43 <bauzas> sean-k-mooney: I just noticed we allow any contributor to flag with +1
16:39:59 <bauzas> but the doc says we should not allow the owner to do it directly
16:40:07 <sean-k-mooney> correct
16:40:12 <sean-k-mooney> we cant make that distinction
16:40:30 <sean-k-mooney> i tried with chanve_owner:0
16:40:43 <bauzas> ok, then we'll need to have a smarter Gerrit query
16:40:43 <sean-k-mooney> but that will not override registered owner
16:40:56 <sean-k-mooney> or we can just discuage it when we see it
16:41:08 <sean-k-mooney> the doc still says they should not flag there own change
16:41:21 <bauzas> yup, educational enforcement :)
16:41:34 <opendevreview> Artom Lifshitz proposed openstack/nova-specs master: Domain names in metadata  https://review.opendev.org/c/openstack/nova-specs/+/840974
16:41:39 <sean-k-mooney> if it ends up being a proablem we can revaluate
16:41:40 <bauzas> ok, let's bikeshed on the names in the gerrit change itself
16:42:07 <bauzas> I don't wanna drag this meeting's time by us disagreeing on how we would label those rights
16:42:19 <sean-k-mooney> ok if there are no objection to the names as written i think we could ask infra to review
16:42:35 <bauzas> but if people care about naming such things, they should review the change
16:43:12 <bauzas> sean-k-mooney: gibi had an objection, but let's continue off this meeting
16:43:20 <sean-k-mooney> ah ok
16:43:23 <bauzas> (about the +2 naming)
16:43:31 <bauzas> #topic Stable Branches
16:43:37 <bauzas> elodilles: are you around N?
16:43:42 <elodilles> yepp
16:43:51 <bauzas> cool
16:43:54 * bauzas drops mic
16:44:12 <elodilles> i did not update the page, though, as there's no news unfortunately,
16:44:54 <elodilles> from yoga till victoria the gate looks OK afaik
16:44:58 <bauzas> ok, then
16:45:05 <bauzas> #info ussuri and older branches are blocked until 'l-c drop' patches merge - https://review.opendev.org/q/I514f6b337ffefef90a0ce9ab0b4afd083caa277e
16:45:17 <bauzas> #info other branches are OK
16:45:30 <elodilles> yepp, still valid ^^^
16:45:49 <elodilles> did not get there to investigate more on ussuri
16:45:53 <elodilles> :-/
16:45:56 <bauzas> s/should be/are for the last item :)
16:46:06 <bauzas> thanks elodilles
16:46:16 <bauzas> last topic
16:46:18 <bauzas> #topic Open discussion
16:46:22 <bauzas> (sean-k-mooney) VDPA
16:46:42 <bauzas> sean-k-mooney: we're listening to you
16:46:50 <sean-k-mooney> :)
16:47:21 <sean-k-mooney> so short version is as agreed at the ptg i filed a bug for the move operation that were blocked but actully working
16:47:33 <sean-k-mooney> and i have a patch to adress it
16:47:45 <bauzas> cool
16:47:52 <sean-k-mooney> i then have 3 patches that follow up adding the remaining life cycle operations
16:48:06 <sean-k-mooney> i would like to proceed with those as a specless blueprint
16:48:12 <sean-k-mooney> those are inteface detach
16:48:17 <sean-k-mooney> suspend which need detach
16:48:36 <sean-k-mooney> and hotplug live migration which just need detach and adding vdpa to a list
16:48:49 <sean-k-mooney> and a compute version bump+ conductor check
16:49:06 <sean-k-mooney> idential to sriov hotplug migraiton
16:49:13 <sean-k-mooney> how do people feel about that
16:49:36 <sean-k-mooney> i have the code writen for everything excpot the compute service bump
16:49:48 <bauzas> hmmmm
16:49:49 <sean-k-mooney> test code is still need so patches are WIP
16:50:11 <bauzas> sean-k-mooney: no RPC changes on the compute service, just a version bump for API check ?
16:50:50 <sean-k-mooney> yep like this https://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L34-L44=
16:51:10 <sean-k-mooney> the sriov live migration code works for vdpa too
16:51:21 <bauzas> I'd say a specless BP seems OK to me
16:51:23 <sean-k-mooney> just need to tell it to hot unplug the interface as we do for direct passthough
16:51:41 <bauzas> for exposing the new lifecycle ops
16:51:53 <sean-k-mooney> the compute service bump is just need for rooling upgrades
16:52:02 <bauzas> I know
16:52:09 <bauzas> but this means there is an upgrade impact
16:52:18 <bauzas> seamless for ops tho
16:52:42 <bauzas> but I don't see any controversial requiring a spec
16:52:46 <sean-k-mooney> yep so the api block will move form the api to conductor baseed on compute service version
16:52:59 <bauzas> so, looks like a feature, but less paper-ish
16:53:25 <bauzas> sean-k-mooney: this will be explained in a feature relnote, so definitely a blueprint
16:53:50 <bauzas> like 'now, nova supports this, only if you have your whole cloud uptodate'
16:53:53 <sean-k-mooney> ok we can continue to discuss in gerrit https://blueprints.launchpad.net/nova/+spec/vdpa-suspend-detach-and-live-migrate is the blueprint
16:54:23 <sean-k-mooney> but yes i can detial this in the release note
16:54:24 <bauzas> we have 5 mins for officially blessing it
16:54:37 <bauzas> do you want to propose https://blueprints.launchpad.net/nova/+spec/vdpa-suspend-detach-and-live-migrate as a specless BP ?
16:55:01 <sean-k-mooney> yes
16:55:20 <bauzas> okay, then anyone DISAGREEING with this ?
16:56:14 <bauzas> looks not,
16:56:47 <bauzas> #agreed https://blueprints.launchpad.net/nova/+spec/vdpa-suspend-detach-and-live-migrate approved for Zed release as a specless BP, no objections so far be seen
16:56:53 <bauzas> voila
16:57:20 <bauzas> sean-k-mooney: a short summary and a better title may help
16:57:31 <bauzas> but I'll approve your BP
16:58:18 <bauzas> that's it for today, any other lastminute item to discuss ?
16:58:54 <bauzas> apparently not
16:58:56 <bauzas> thanks all
16:59:03 <bauzas> productive meeting again
16:59:06 <bauzas> #endmeeting