16:00:07 <gibi> #startmeeting nova
16:00:08 <openstack> Meeting started Thu Mar 19 16:00:07 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:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:11 <openstack> The meeting name has been set to 'nova'
16:00:37 <gmann> o/
16:00:49 <gibi> o/
16:01:45 <lyarwood> o/
16:02:33 <sean-k-mooney> o/
16:02:41 <gibi> lets get started
16:02:41 <gibi> #topic Last meeting
16:02:51 <gibi> #link Minutes from last meeting: http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-03-12-16.00.log.html
16:02:58 <gibi> gibi promised to follow up on the ML about the plans for a virtual PTG. This is still an open AP on gibi.
16:03:26 <gibi> especially as the fundation is now cancelled the physical Vancuver event
16:03:44 <gibi> anything else from the last meeting to bring back?
16:04:25 <gibi> #topic Bugs (stuck/critical)
16:04:33 <gibi> No Critical bugs
16:04:33 <gibi> #link 99 new untriaged bugs (-12 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
16:04:36 <gibi> Thank you for started reducing our bug backlog. Please continue.
16:05:05 <gibi> gmann started an etherpad #link https://etherpad.openstack.org/p/nova-bug-triage-ussuri
16:05:19 * lyarwood clicks
16:06:31 <gmann> i started by doing few bug triage for this week, hope to burn more next week.
16:06:47 <artom> What are we supposed to note in the etherpad?
16:06:49 <gibi> relevant ML thread #link http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013413.html
16:07:32 <gmann> basica idea is collect the info or report like neutron does. but wihtout rotation. it will be many members doing at same time
16:08:04 <gmann> in QA we do the same and in office hour we try to discuss few which need discussions or review if fix is ready etc
16:08:30 <gmann> if that help ?
16:08:40 <artom> So basically if we're not sure about a bug, note it down in that etherpad?
16:09:32 <gmann> yeah. we can add bugs which are triaged in that week to know weekly progress but that can be known from LP
16:09:34 <gibi> I think it help to highlight relevan bugs or ask for help
16:09:43 <gmann> exactly
16:10:09 <gibi> let's try and see if it helps
16:10:14 <artom> Should it become a recurring agenda item in meetings?
16:10:41 <gibi> #action gibi add bug report etherpad to the meeting as a topic
16:10:58 <gmann> i think in nova channel more than meeting as it need discussions etc. meeting can just check how much we burned in that week,
16:11:20 <gibi> I will link the pad for the next couple of meeting to socialize it
16:11:23 <gmann> so status kind of check in meeting and detail discussion on channel ?
16:11:23 <artom> Yeah, maybe. Bugs are already a recurring item, so...
16:11:30 <gmann> yeah
16:11:33 <gibi> gmann: yepp
16:11:46 <gibi> anything else about bug triage?
16:12:24 <gibi> melwitt sent nova gate status mail to the ML http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013393.html
16:12:27 <gibi> melwitt, lyarwood, gmann: Do you need help?
16:12:50 <gibi> I saw good progress on the mentioned items
16:13:29 <gmann> i will get tempest fix merge soon which occur randomly
16:13:37 <gmann> default network one
16:13:45 <gibi> gmann: thanks
16:13:53 <lyarwood> yeah good progress on most of this
16:14:02 <lyarwood> still a few issues to hunt down
16:14:09 <gibi> thank you all of you
16:14:16 <gibi> anything else regarding bugs?
16:14:56 <gibi> #topic Release Planning
16:15:01 <gibi> Two weeks until "Final release for non-client libraries" (Apr 3.)
16:15:21 <gibi> do we have must have items in os-vif os-traits os-resource-classes to release?
16:15:26 <gibi> #link https://review.opendev.org/#/q/project:openstack/os-vif+status:open
16:15:32 <gibi> #link https://review.opendev.org/#/q/project:openstack/os-resource-classes+status:open
16:15:38 <gibi> #link https://review.opendev.org/#/q/project:openstack/os-traits+status:open
16:16:53 <sean-k-mooney> for os-vif there is one feature that melonox is interested in
16:16:59 <gibi> based on the silence and the emptiness of the review queue I guess the answer is no. But I will ask next week
16:17:03 <sean-k-mooney> however im not sure the ovs patchs have merged yet
16:17:10 <sean-k-mooney> so that is the main blocker to merging it
16:17:21 <gibi> sean-k-mooney: do you have a link?
16:17:31 <sean-k-mooney> so nothing that is not blocked on external factors
16:17:39 <sean-k-mooney> yep one sec
16:18:17 <sean-k-mooney> https://review.opendev.org/#/c/705018/ and https://review.opendev.org/#/c/702857/ i think
16:18:42 <gibi> thanks
16:18:51 <gibi> anything else about the release?
16:20:00 <gibi> #topic Stable Branches
16:20:11 <gibi> lyarwood: anything newsworthy?
16:20:35 <lyarwood> we've got a growing core backlog of reviews
16:20:44 <lyarwood> I'm going to work my way through the following if others can also take a look
16:20:52 <lyarwood> #link https://review.opendev.org/#/q/project:openstack/nova+label:Code-Review%253D%252B2+branch:%255Estable/.*+status:open+NOT+is:reviewer+NOT+is:owner
16:21:14 <lyarwood> stable/pike should also be unblocked by https://review.opendev.org/#/c/713036/ btw
16:21:27 <lyarwood> rebasing changes on it now and will +W later once they are passing
16:21:59 <gibi> thanks
16:22:17 <gibi> #topic Sub/related team Highlights
16:22:21 <gibi> Placement (tetsuro)
16:23:02 <gibi> I think the only open item is consumer_types
16:23:11 <gibi> I saw some discussion between dansmith and melwitt about it
16:24:01 <gibi> API (gmann)
16:24:12 <gmann> one thing to share. i added two flavor API cleanup (removal of is_public flag  and id from create request) in api cleanup etherapd as discussed on channel with sean-k-mooney . - https://etherpad.openstack.org/p/nova-api-cleanup
16:24:44 <gmann> idea is to collect these kind of cleanup and later in V or W we discuss what all should be done. and we do all those cleanup in single vesion bump same way we did in stein
16:24:45 <gibi> gmann: I guess these are items for Victoria
16:24:50 <gmann> yeah or later
16:24:54 <gibi> OK
16:24:57 <gibi> thanks for collecting them
16:25:26 <gibi> #topic Stuck Reviews
16:25:28 <gmann> if anyone find such worthy cleanup to do but not worth for version bump, you can add in that etherpad
16:25:49 <gibi> nothing on the agenda. is there any stuck review to discuss?
16:26:46 <gibi> #topic Open discussion
16:27:01 <gibi> (gibi): I'm getting hit by RH-only patches recently as core-company diversity is low. Options? Opinions? (I'm just testing the waters here)
16:27:27 <gibi> I'm totatlly fine getting those pings btw
16:28:57 <sean-k-mooney> ya so i am trying to ping redhat cores to review before reaching out ot non redhaters
16:28:58 <stephenfin> Personally, I think core numbers are as much if not a bigger issue
16:29:00 <lyarwood> I think we are getting closer to having to drop the RH rule tbh
16:29:26 <lyarwood> and yes core numbers are also an issue at the moment
16:29:46 <sean-k-mooney> there is definetly a time zone aspect
16:29:49 <artom> I kinda assumed the trifecta rule was implicitly dropped
16:29:57 <artom> Out of sheer practicality
16:30:01 <sean-k-mooney> gibi you tend to be around more offent then say alex
16:30:09 <sean-k-mooney> at least when im on
16:30:24 <artom> With Matt and Eric gone, it leaves only gibi and alex_xu, which is a massive burden to shoulder
16:30:25 <gibi> artom: I don't think we dropped the rule not even technically
16:30:36 <lyarwood> yeah it wasn't dropped
16:30:38 <sean-k-mooney> we have not dropped it
16:30:50 <lyarwood> but I think we are getting to a point now where we might have to
16:30:54 <lyarwood> before we drive gibi mad
16:30:56 <gmann> in denver, it was discussed but not dropped.
16:31:16 <gmann> with current situation, it make sense to revisit it.
16:31:25 <stephenfin> I think we need more cores first, tbh
16:31:33 <artom> stephenfin, who though?
16:31:58 <gibi> stephenfin: I agree that both the number of cores and the diversity is a problem
16:32:11 <gibi> if we want to keep the rule
16:32:20 <artom> stephenfin, let's say lyarwood - he's still RH
16:32:35 <artom> How many consistent non-RH contributors are there who aren't already cores?
16:33:32 <gibi> brinzhang_ expressed the wish to become a core
16:33:36 <gibi> and he is not RH
16:33:39 <gibi> afaik
16:33:41 <sean-k-mooney> there are peole like gmann who are sme in specific areas
16:33:58 <stephenfin> I was trying to find brinzhang_'s NIC
16:34:02 <stephenfin> *nick
16:34:03 <stephenfin> :)
16:34:37 <stephenfin> and also, yeah, there are a few SMEs
16:34:40 <sean-k-mooney> another approch is to take the lutenit / subsystem maintainer model
16:34:42 <stephenfin> though increasingly few
16:35:49 <sean-k-mooney> i guess this is something we have to monitor but we are getting to a point where it will be hard to progress if maintian the current workflow.
16:36:01 <stephenfin> Personally, if there's a subsystem that doesn't have enough eyes on it already, it's unlikely we'll be able to find a maintainer that's up to scratch
16:36:03 <artom> I guess it's for cores to decides between themselves - but as much I agreed with the trifecta rule when there was wider diversity, I'm not sure it still makes sense
16:36:03 <gmann> true.
16:36:28 <gibi> artom: tend to agree
16:36:59 <stephenfin> If someone's good enough to maintain a subsystem, they're good enough to chip in with the rest of it, IMO
16:37:11 <sean-k-mooney> one thing we did in os-vif was due to the lack of diversity/active review we have always taken a much more relaxed approch.
16:37:14 <gmann> and it is always trust basis not to +2/+A the area or things you are not 100% sure.
16:37:26 <stephenfin> yup, exactly ^
16:37:27 <gibi> agree.
16:37:28 <artom> sean-k-mooney, os-vif is much smaller in scope though
16:38:10 <stephenfin> yeah, os-vif is tiny by comparison
16:38:27 <gibi> OK. I will drop a mail to the ML about the RH only rule. We need at least a core consensus to remove that
16:38:29 <artom> We can do both though - relax the trifecta rule for now (not necessarily abolish - like, RH can still ping gibi or alex_xu for reviews, but gibi can feel free to say "just do it yourselves, I don't have bw"), while at the same time ramping up new non-RH cores
16:38:49 <sean-k-mooney> it is but size is not really relevent here. but ya lets continue on ML
16:38:49 <lyarwood> +1
16:38:56 <artom> With the intent to eventually re-instate the full trifecta rule
16:39:07 <stephenfin> we should also be looking for opportunities to minimise the amount of work we need to do
16:39:19 <artom> Amen brother
16:39:26 <lyarwood> stephenfin: looking to rm -rf more code?
16:39:30 <gibi> :)
16:39:46 <stephenfin> Well, yeah. Marking the likes of the Xen and VMWare drivers as deprecated is a good step in the right direction IMO
16:40:00 <lyarwood> yup was just thinking of that
16:40:15 <gmann> hiring more people in core team also encourage them to learn/help in other area too as stephenfin mentioned early, .
16:40:15 <lyarwood> the cinder folks are going through the same process at the moment with their drivers FWIW
16:40:19 <stephenfin> I don't care about them and if no one else does, rm -rf seems appropriate :)
16:40:34 <stephenfin> they're planning to keep them in tree though
16:40:46 <lyarwood> even the unsupported ones?
16:40:49 <lyarwood> sorry I missed that
16:40:58 <lyarwood> anyway that's OT
16:40:59 <sean-k-mooney> lyarwood: yes until they casue a breakage in the ci
16:41:04 <gmann> they have removal rule also which recently merged
16:41:25 <gmann> yeah CI health is one criteria
16:41:35 <lyarwood> yeah sorry that's what I was thinking by unsupported, CI broken etc.
16:41:41 <sean-k-mooney> we dont have a ci for xen or vmware right now so i guess it cant break it
16:41:42 <gmann> but cinder has too many compare to nova
16:42:19 * stephenfin would put money on Xen not being functional out of the box today
16:42:25 <dansmith> sean-k-mooney: vmware ci has been started back up, but I've only seen it fail :)
16:42:31 <gibi> there is some work ongoing around the vmware CI, dansmith saw some votes coming in
16:42:40 <sean-k-mooney> dansmith: oh good to know
16:42:54 <stephenfin> nice one
16:43:06 <sean-k-mooney> that proably means we work something while it was offline
16:43:19 <sean-k-mooney> although it could just be problems with the initall setup
16:43:32 <gibi> OK any other open discussion topic before we run out of time?
16:43:42 <dansmith> I think it's highly unlikely that all the placement and resource stuff works as expected with either of those drivers at this point
16:44:17 <sean-k-mooney> on a related note im not sure we are going to start any of the numa in placmenet stuff this cycle.
16:44:18 <gibi> if not then I'm fine continue discussing cores and drivers
16:44:29 <sean-k-mooney> im hoping to take a look at it after cyborg stuff merges
16:44:40 <sean-k-mooney> but i expect that to mainly happen in Victoria at this point
16:44:42 <gibi> yeah cyborg has higher on my list too
16:44:47 <stephenfin> sean-k-mooney: unlikely. bauzas has more important stuff on his plate atm I think /o\
16:45:15 <sean-k-mooney> so that basically just a heads up that that will slip
16:45:38 <sean-k-mooney> in terms of cyborg
16:45:48 <sean-k-mooney> do we know if sundar is around much longer
16:45:56 <dansmith> I was just talking to him,m
16:46:01 <dansmith> he has one week left to push,
16:46:06 <dansmith> but also really wants to argue about useless comments
16:46:21 <dansmith> so...some work will be done, but we'll see how much
16:46:32 <sean-k-mooney> ok
16:46:43 <dansmith> after that we'll need someone to pick up ownership of it
16:46:54 <dansmith> which I can do, but I'd rather it be you so I can keep reviewing
16:47:06 <sean-k-mooney> ya
16:47:18 <sean-k-mooney> i can swap to adressing the comments if needed
16:47:36 <sean-k-mooney> but ill leave it to sundar while he is about
16:48:00 <dansmith> yep
16:48:08 <gibi> sounds like a plan :)
16:48:18 <gibi> anything else to discuss?
16:49:28 <gibi> then thank you for joining today!
16:49:34 <gibi> #endmeeting