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