16:00:04 <gibi> #startmeeting nova
16:00:07 <openstack> Meeting started Thu Apr 30 16:00:04 2020 UTC and is due to finish in 60 minutes.  The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:10 <openstack> The meeting name has been set to 'nova'
16:00:28 <dansmith> o/
16:00:30 <gibi> o/
16:00:37 <melwitt> o/
16:01:06 <lyarwood> o/
16:01:42 <artom> ~o~
16:01:59 <gibi> OK lets get started
16:02:04 <gibi> #topic Last meeting
16:02:13 <gibi> #link Minutes from last meeting: http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-04-23-16.00.log.html
16:02:21 <gibi> anything we have to bring back from the last meeting?
16:03:21 <gibi> if not then moving forward to
16:03:22 <gibi> #topic Bugs (stuck/critical)
16:03:32 <gibi> No Critical bugs
16:03:38 <gibi> #link 38 new untriaged bugs (-15 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
16:03:49 <gibi> we need to keep an eye of possible regressions as Ussuri release is in 2 weeks
16:03:55 <gibi> RC critical bugs are tagged with ussuri-rc-potential #link https://bugs.launchpad.net/nova/+bugs?field.tag=ussuri-rc-potential
16:04:05 <gibi> we have one bug tracked as RC2 potential
16:04:21 <gibi> https://bugs.launchpad.net/nova/+bug/1875418
16:04:21 <openstack> Launchpad bug 1875418 in OpenStack Compute (nova) "Generated policy.json in Ussuri is broken by default" [High,In progress] - Assigned to Ghanshyam Mann (ghanshyammann)
16:04:31 <gibi> gmann is working on the upgrade check for that
16:04:32 <dansmith> we're going to call that fixed by the status tool patch/
16:04:45 <gmann> o/
16:05:23 <gibi> dansmith: do you mean fixed for ussuri?
16:05:49 <dansmith> gibi: yeah, meaning.. is the merging/backporting of the status fix all we have or are going to do to call that rc2 bug fixed?
16:06:01 <dansmith> not suggesting there is more, just asking if there is so I can help review
16:06:13 <gibi> I think that is all for stable/ussuri and for RC2
16:06:19 <dansmith> ack
16:06:26 <gibi> we have topic added to the PTG to further discuss
16:06:29 <dansmith> gmann is addressing feedback from me on that in the last hour
16:07:11 <gibi> dansmith, gmann: tomorrow is holiday here but I will check back for tha bug fix either today or tomorrow
16:07:15 <gmann> yeah, working on those. and we can discuss the json format things in PTG
16:07:38 <gibi> gmann: thanks
16:07:39 <gmann> gibi: I will bring it in hour or early.
16:07:39 <dansmith> gibi: okay I can try to get someone else to +W after I've +2d so we can move it along
16:07:56 <gibi> dansmith: sure, don't have to wait for me
16:08:13 <gibi> and thanks for reviewing it
16:08:32 <gibi> any other bugs we should discuss?
16:08:44 * bauzas waves late
16:09:43 <gibi> #topic Release Planning
16:09:57 <gibi> TODOs are tracked in the etherpad #link https://etherpad.opendev.org/p/nova-ussuri-rc-potential
16:10:01 <gibi> We cut RC1 last week
16:10:07 <gibi> We will need RC2 after the policy upgrade check is merged and backported to stable/ussuri #link https://review.opendev.org/#/c/723645/
16:10:15 <gibi> Deadline for last RC is May 8
16:10:39 <gibi> is there anything else to discuss about the release?
16:11:21 <gibi> #topic Stable Branches
16:11:37 <gibi> 19.2.0 form stable/stein has been released https://review.opendev.org/#/c/723357
16:11:42 <gibi> lyarwood any other news?
16:11:47 <lyarwood> Nothing from me no.
16:11:54 <gibi> lyarwood: thanks
16:12:18 <gibi> #topic Sub/related team Highlights
16:12:26 <gibi> Placement (tetsuro)
16:13:07 <gibi> I think I will remove Placement from the meeting agenda
16:13:18 <gibi> tetsuro: feel free to ping me about it
16:13:25 <gibi> API (gmann)
16:13:33 <gmann> not much to share except policy stuff already discussed.
16:13:46 <gmann> few API things are under review
16:14:08 <gibi> gmann: thanks
16:14:41 <gibi> Libvirt (bauzas)
16:15:03 <bauzas> nothing yet, we just created the subteam
16:15:17 <bauzas> we have few new folks, thanks for all of them :)
16:15:23 <aarents> I just put my things on https://etherpad.opendev.org/p/nova-libvirt-subteam
16:15:55 <bauzas> yeah, we somehow need to organize some team 'meeting'
16:16:17 <gibi> bauzas: thanks
16:16:21 <aarents> k
16:16:55 <gibi> #topic Stuck Reviews
16:17:16 <gibi> nothing on the agenda, is there anything to bring up?
16:17:56 <gibi> #topic Virtual PTG planning
16:18:09 <gibi> Meeting time slots has been booked based on the doodle results #link http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014523.html
16:19:11 <gmann> gibi: you mean on this- https://ethercalc.openstack.org/126u8ek25noy
16:19:12 <gibi> I think we can still extend those slots if we want but I had to book someting due to fundation deadline
16:19:34 <gibi> gmann: yes, the overall schedule is in that ethercalc
16:19:58 <gibi> nova is in the Rocky column
16:20:28 <gmann> ah, saw now, thanks
16:20:39 <gibi> anything else regarding the virtual PTG?
16:21:21 <gibi> #topic Open discussion
16:21:36 <gibi> nothing on the agenda, is there anyting?/
16:22:10 <artom> So, before bauzas brings up the backport that he told me wants to bring up
16:22:37 <artom> Placement subteam's absence lead me to look at placement as a project... who's still around there? efried left, cdent?
16:22:47 <gibi> cden also left
16:22:54 <bauzas> tetsuro I think
16:22:56 <artom> Is tetsuro the only one?
16:23:03 <gibi> tetsuro still keeping the light on
16:23:19 <artom> OK - something to keep an eye on, since we're pretty heavily dependant on placement
16:23:38 <bauzas> I think I'm still a placement-core tho :)
16:23:42 <gibi> me too
16:23:47 <gibi> and I'm OK to get bugs to fix
16:23:53 <gibi> in placement
16:24:02 <bauzas> as well
16:24:03 * dansmith resists the urge to make a sarcastic remark
16:24:34 * bauzas can't resist
16:24:41 <bauzas> to ask*
16:24:44 <artom> Aha, I just checked https://review.opendev.org/#/admin/groups/1936,members
16:24:53 <artom> OK, so still operational, though that list could use updating
16:24:57 <artom> Reassuring :)
16:25:25 <artom> OK, that's it for that - bauzas, wanna introduce the placement audit backport?
16:25:54 <bauzas> so, the question is basically, should we accept to backport the placement audit command for Train ?
16:26:06 <bauzas> it's a bugfix :p
16:26:10 <artom> https://review.opendev.org/#/q/topic:placement-audit-backport+(status:open+OR+status:merged)
16:26:15 <bauzas> artom said it's a DNM
16:26:21 <artom> I did it upstream first because we need it in our product downstream
16:26:29 <artom> But assumed it has no chance, so DNM'ed it
16:26:36 <bauzas> tbh, Red hat doesn't really need to have it backported to Train
16:26:37 <artom> Wanted to get upstream CI on it
16:26:52 <artom> It starts to get ugly around stein :/
16:26:54 <bauzas> but maybe other operators would love to get it without red hat :)
16:27:08 <artom> We need it in queens, and therefore train as well, to avoid regressions
16:27:11 <bauzas> hence my question
16:28:54 <gibi> I can see the value in it
16:29:19 <gibi> did we backported nova-mange CLI additions before?
16:29:39 <bauzas> heal_allocations maybe
16:29:44 <melwitt> we usually did not. which is why at the time I backported heal_allocations to queens downstream only
16:29:46 <bauzas> I don't remember correctly tho
16:29:57 <melwitt> because it was nacked upstream
16:29:58 <bauzas> kk
16:30:11 <bauzas> again, it's not b/c redhat
16:30:19 <bauzas> just in case operators want them
16:30:32 <melwitt> but, we did backport the --instance and one other option to heal_allocations, there was an ML thread mriedem made about it to ask for ack about it
16:31:00 <aarents> We will migrate soon to stein so yes.. audit is a good to have for us
16:31:43 <melwitt> http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010572.html
16:31:46 <gibi> Do we see any future issue we we merge those backports?
16:32:13 <dansmith> did queens have the different allocation structure for migations? I forget when that was
16:32:14 <bauzas> maybe CERN would like it ?
16:32:28 <bauzas> dansmith: at least because queens wasn't having nested RPs
16:32:30 <dansmith> if so, I would expect the audit command to need changes
16:32:44 <dansmith> bauzas: we didn't need nested for the migration thing
16:32:55 <bauzas> oh for migrations ? my bad.
16:33:35 <bauzas> afair, we did this in Ocata
16:33:42 <bauzas> ie. after Newton
16:33:49 <bauzas> if that's what you asked
16:34:49 <dansmith> and it was gone in pike?
16:34:50 <dansmith> I don't remember, I'd have to go look
16:35:30 <bauzas> https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/migration-allocations.html
16:35:31 <dansmith> anyway, I would think there's some real non-trivial validation that would need to happen to make sure it's going to do the right thing for the older releases, not just a trivial backport
16:35:36 <bauzas> found
16:35:47 <bauzas> err, s/Newton/pike
16:36:00 <artom> dansmith, oh, even without that validation, the backport is non-trivial
16:36:24 <dansmith> bauzas: that's queens, which means queens could still have doubled migration allocations I think
16:36:34 <dansmith> which means the audit has to be able to handle that, but wouldn't in master
16:37:14 <dansmith> anyway, i think this is pretty contrary to the type of thing we'd normally consider for stable, although we have done things for operator tooling that are more feature-y, but not quite as big as this, AFAIK
16:37:37 <bauzas> dansmith: tbh, I just asked for backporting to Train and maybe Stein upstream
16:37:41 <dansmith> it would be super bad to backport this, have someone start using it thinking it's a harmless prophylactic and then break their allocations
16:37:45 <bauzas> for queens, meh
16:37:51 <dansmith> oh, I thought for queens
16:38:17 <gibi> can we agree to allow merging the cleaner part (train, stein) ?
16:38:33 <artom> Pretty much only train, stein's not even that clean :(
16:38:38 <bauzas> well, Rocky and older releases are in EM
16:38:41 <artom> Well, I'll let the reviewers judge
16:38:59 <bauzas> while Train and Stein are still in Maintenance
16:39:07 <bauzas> hence my question
16:39:10 <dansmith> so, what's the big reason for this?
16:39:10 <bauzas> sorry if I was unclear
16:39:26 <dansmith> because redhat wants upstream CI on that? are any operators asking for it to fix things?
16:39:43 <bauzas> again, nothing really needed for redhat
16:39:53 <bauzas> just proposing to have it upstream in case people wanted it
16:39:54 <gibi> aarents already expressed the need above
16:40:19 <artom> dansmith, for me it was purely procedural - push as DNM to allow me to do it one release at a time (downstream our branches for stein and rocky are EOL) and to get upstream CI
16:40:22 <bauzas> we can just work silently downstream and ask operators to pay the bill
16:40:28 <dansmith> gibi: I didn't see a need, just a nice to have
16:40:33 <bauzas> but heh, we're discussing this now in between all of us
16:40:36 <gibi> dansmith: true, my bad
16:40:57 <bauzas> either way, here is my proposal
16:40:58 <gibi> artom, bauzas: could you ask the operators on the ML?
16:41:00 <artom> dansmith, I wasn't actually expecting that this discussion would come up
16:41:07 <artom> Blame bauzas for that ;)
16:41:12 <dansmith> gibi: in the past, we've backported operator tooling generally because of some thing we realized was broken and they needed it to clean up the mess or something
16:41:23 <bauzas> I can take the blame
16:41:30 <bauzas> I just wanted to help others, that's it
16:41:46 * artom 🚎 <- bauzas
16:41:47 <dansmith> gibi: asking operators "would you like to have a thing" is either going to elicit no response or a yes.. nobody will say no :)
16:42:08 <gibi> dansmith: then I don't know how to asess the need
16:42:16 <bauzas> ok ok, looks to me we discussed too much on this one
16:42:29 <bauzas> if nobody really expresses the need here, fair enough
16:42:55 <dansmith> gibi: I usually assess the need when someone comes asking for it, or we help someone find, fix an issue and identify some piece oftooling we need to give them to fix the mess
16:43:10 <bauzas> tbh, the bug was reported a while ago
16:43:19 <bauzas> and because of *ME*
16:43:24 <bauzas> it took age to merge
16:43:26 <dansmith> gibi: like the recent thing we broke in the db migration, the operator brought it, we fixed, backported the thing needed and helped him clean up the database corruption
16:43:26 <bauzas> ages*
16:43:40 <bauzas> so it would be a bit fair to propose the change a bit down the road
16:44:00 <gibi> dansmith: OK thanks for the explanation
16:44:03 <bauzas> and again, blame me for my perpetual PTOs
16:44:26 * artom blames all of France
16:44:42 <bauzas> maybe mnaser has a thought on this ?
16:45:00 <bauzas> he's part of the solution
16:45:12 <bauzas> https://bugs.launchpad.net/nova/+bug/1793569
16:45:12 <openstack> Launchpad bug 1793569 in OpenStack Compute (nova) "Add placement audit commands" [Wishlist,Fix released] - Assigned to Sylvain Bauza (sylvain-bauza)
16:45:37 <bauzas> but he's not in this chat
16:45:52 <bauzas> okay, i think we're ratholing
16:45:55 <dansmith> yes
16:45:57 <melwitt> I guess I would suggest an ML post and ping mnaser, belmiro, and so on to reply
16:45:58 <artom> bauzas, face it, it's dead Jim
16:46:04 <melwitt> if you would like some inputs
16:46:12 <bauzas> cool
16:46:31 <dansmith> again, the only outcome from that will be yes :)
16:46:31 <bauzas> in the meantime, there is no harsh to remove the DNM tag on the Stein and Train proposals
16:46:53 <bauzas> and leave people vote on it :)
16:47:06 <bauzas> if nobody steps up, cool bro
16:47:07 <artom> bauzas, without leaking too much RH stuff in here, I'd like to remind you that it's supposed to be an escalation, so time is important
16:47:07 <dansmith> bauzas: I'll go do that now
16:47:44 <bauzas> I wouldn't argue here about the priority
16:47:45 <gibi> OK. I think we have a way forward here
16:47:57 <gibi> anything else to discuss for the open?
16:48:20 <bauzas> dansmith: thanks
16:48:33 <gibi> refering back to artom's earlier question about placement, it turned out that there was no active stable maint placement core
16:48:44 <gibi> but efried fixed it now
16:48:57 <artom> \o/
16:48:58 <dansmith> gibi: that doesn't fix it,
16:49:00 <bauzas> don't nova-core can merge things ?
16:49:04 <dansmith> it just means there are people on tat team :)
16:49:05 <artom> /o\
16:49:17 <bauzas> or the stable-maint cores ?
16:49:20 <dansmith> doesn't mean they're active I mean
16:49:31 <gibi> dansmith: it allows us to repopulate the team in gerrit
16:49:59 <dansmith> gibi: I'm just tongue-in-cheek arguing over the definition of "active" :P
16:50:24 <gibi> dansmith: hehh. I can grow a leg there if there is need for backports
16:50:42 <bauzas> we're taking of a project where 90% of its code is either SQL or API ?
16:50:47 <melwitt> I will make sure to check stable branch over there periodically
16:50:53 <gibi> melwitt: thanks!
16:50:58 <stephenfin> nova-core == placement-core == nova-stable-maint == placement-stable-maint would be so much simpler
16:51:11 <bauzas> sounds a particular good candidate for getting a shit ton of acceptable backports :D
16:51:20 <gibi> bauzas: :D
16:51:32 <bauzas> I mean, seriously,
16:51:37 <bauzas> is that a thing ?
16:51:46 <stephenfin> nah. more that the trivial stuff wouldn't be held up
16:51:50 <bauzas> not that the code isn't broken
16:52:25 <bauzas> just that the stable policy prevents us to merge a huge number of changes except bugfixes that no longer return 500
16:52:46 <stephenfin> yup, I wouldn't expect that to change
16:54:11 <gibi> OK. anything else to discuss?
16:54:48 <gibi> thank thanks for joining
16:55:02 <gibi> #endmeeting