16:00:13 #startmeeting nova 16:00:14 Meeting started Thu Dec 17 16:00:13 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:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:17 The meeting name has been set to 'nova' 16:00:34 welcome everyone on the last nova meeting of 2020 16:00:41 \o 16:00:52 o/ 16:02:06 \o (also on a downstream meeting) 16:02:11 #topic Bugs (stuck/critical) 16:02:22 No Critical bugs 16:02:26 #link 7 new untriaged bugs (-15 since the last meeting): #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 16:02:30 which is an all time llow 16:02:35 since I'm follwing this 16:02:44 thank you all for bugtriage 16:03:02 is there any specific bugreport we need to talk about today? 16:04:34 #topic Gate status 16:04:39 master and stable/victoria has been unblocked 16:04:46 work on the other stable branches is still ongoing 16:04:50 to unblock them 16:04:59 (more on stable later) 16:05:05 Classification rate 45.7% (-4 since the last meeting) #link http://status.openstack.org/elastic-recheck/data/integrated_gate.html 16:05:26 I guess I can say now that this % not in correlation with our known and unknown gate failures 16:05:50 or at least I didn't see that correlation in the last couple of months 16:06:02 so I will stop following this number 16:06:38 but still request everyone if they see a CI failure that is due to the specific patch under test then please look at it, file a bug and propose a E-R query 16:06:51 so we can get fix our flaky runs 16:07:08 any specific gate failre we need to talk about today? 16:08:59 #topic Release Planning 16:09:03 Milestone 2 is 22nd of Jan 16:09:13 which is also spec freeze for us 16:09:34 considering the coming holiday season we have rughly 2 real weeks left until spec freeze 16:09:47 I assume that won't matter too much. It seems unlikely we'll get to work on more specs than we already have 16:10:32 yeah, I also think that we are pretty full, but spec feeze also means that we will look less at any spec proposed unit after FF 16:11:03 so if somebody needs to close the spec work before we forget all the context then it is time 16:11:14 ah, fair 16:11:45 any other release specific topic? 16:12:50 #topic Stable Branches 16:12:52 o/ 16:13:07 (I'm going to copy the update from elod) 16:13:15 stable gate fixes are progressing, though slowly 16:13:21 gate of victoria, queens and pike should be OK 16:13:25 for ussuri the patch is on the gate (https://review.opendev.org/766738) 16:13:31 for train: first stein needs to be fixed, due to grenade job (errors are regarding: wrong bandit release + lower-constraints) 16:13:36 for stein the patch needs some care (bandit + lower-constraints, https://review.opendev.org/766487) 16:13:43 for rocky the patch is on the gate (https://review.opendev.org/766492) 16:13:46 EOM 16:14:04 also there is a patch from lyarwood @ train: https://review.opendev.org/c/openstack/devstack/+/766622 16:14:04 thanks elod 16:14:09 np 16:14:25 and thanks all who pushing the fixes for the stable branches 16:15:04 any other stable related info? 16:15:17 nothing from me 16:16:06 #topic Sub/related team Highlights 16:16:10 Libvirt (bauzas) 16:16:22 nothing to tell, sir. 16:16:45 thanks 16:16:50 #topic Open discussion 16:16:54 there are two on the agenda 16:17:01 (stephenfin): let's agree on the way forward about #link https://review.opendev.org/c/openstack/nova-specs/+/765797/1/specs/wallaby/approved/modernize-os-hypervisors-api.rst#205 16:17:25 so yeah, really quick 16:17:28 reading the comments from sean-k-mooney and gmann I feel everybody is OK what is proposed in the spec 16:17:43 we just acknowledged that there could be other solutions too 16:18:05 ack, so you're thinking add the field to the main API response and drop the special '/uptime' endpoint? 16:18:12 rather than dropping that info entirely? 16:18:51 yeah, I'm OK with your proposal to move the uptime 16:18:51 I am fine with that. 16:18:59 sean-k-mooney: any last words? :) 16:19:01 sweet, I'll respin the patches to do that so 16:19:13 sean-k-mooney is in a meeting with me but will respond after the meeting I suspect 16:19:26 sean-k-mooney would never disagree though :P 16:19:31 OK, cool :P 16:19:35 then moving on 16:19:38 nice :) 16:19:47 another from the agenda 16:19:49 (Yumeng): cyborg GPU support spec has been updated https://review.opendev.org/c/openstack/nova-specs/+/750116 16:20:02 there is one controversal thing now in it 16:20:05 i would prefer to drop it entirely but im ok with the proposal 16:20:12 sean-k-mooney: thanks 16:20:16 i just wanted to raise the option of droping it 16:20:36 so yes moving on 16:21:00 so when cyborg adds GPU support we will have to ways to support vGPUs to guest 16:21:10 the current nova only way, and the new nova + cyborg way 16:21:34 I do see that in the long run we should no spend effort keeping both solution supported 16:21:56 I see this similar (but smaller scale) to how we cut out nova net 16:22:21 bauzas seems to have issues with this or around this 16:22:33 https://review.opendev.org/c/openstack/nova-specs/+/750116/14/specs/wallaby/approved/support-vGPU-nova-cyborg-interaction.rst#225 16:22:41 I'm not opposed of having cyborg supporting vgpus 16:22:57 I'm opposing of claiming to deprecate stuff in nova because cyborg 16:23:15 but why we pay double cost for this feature? 16:23:33 (and I'm not saying to deprecate it now, I say to deprecate in the future when cyborg support is stable) 16:23:38 my only technical concern I have with this spec is to make sure that most of the nova usage is done by using the same modules and methods 16:23:51 so this prevents the double cost 16:24:13 the mdev management will be doubled in libvirt driver + in cyborg agent as far as I see 16:24:55 gibi: we could make it unique if that's really a problem 16:25:14 by using a common dependency 16:25:24 but I feel this is premature 16:26:04 so I'm coming from the point where I tried to find the reason why cyborg adds support for something openstack already supports 16:26:19 and I do accept that a unified accelerator handling API is good for the end users 16:26:58 but then I realized that after cyborg we will have to ways to do the same thing. So it is not just doubled implementation vise but doubled API vise as well 16:27:26 I personnally have thoughts on what cyborg is good at 16:27:43 providing an inventory API 16:27:47 and I do understand that deciding about deprecation is premature. but I want to start discussion early to avoid the long nova-net neutron coexistence case with cyborg 16:28:14 that's a different case here 16:28:23 and that's exactly why I want to share code 16:28:49 how it is different (other the size) 16:28:50 if we need to make it single, we can discuss on a common dependency that both nova and cyborg would pull for mdev management 16:29:25 but the common dependency only solves the code duplication but on the API flow duplication for vGPU support 16:29:30 gibi: quantum was incepted from scratch, here we propose to have cyborg interacting with the existing nova bits the same way that nova does 16:30:07 cyborg is from the scratch and neutron does interface with nova similarly how cyborg today interface with nova 16:30:52 either way, I feel this discussion is worth being held at a PTG :) 16:30:58 totally agree 16:31:09 I just wanted to put my position out there early 16:31:10 I'm not opposed to remove the mdev management in nova *eventually* 16:31:32 but we're waaaays steps ahead of this 16:32:00 I want to plan the eventual removal early so that we not end up with nova-net 2 16:32:05 and I'd tell a solid base of users playing with cyborg and a various amount of contributors would make the leap shorter 16:32:35 agree 16:32:43 we need to see how cyborg is adopted out there 16:33:02 and ideally being productized 16:33:20 I haven't heard yet of distros providing it 16:33:22 I do see that my company is looking into adding cyborg to the product 16:33:31 but it is not in yet 16:33:54 I'll be frank, my own company isn't getting interested in productising it *yet* 16:34:10 not my own thought, but rather a top-level view 16:34:43 good to know these bits 16:34:54 so, I apologize for me dragging it a bit, but removing it from nova would seriously mean hard work for us 16:35:07 anyhow it was good to talk about it bauzas, I will link this discussion tot he review 16:35:10 and a non-trivial amount of resources to consider 16:35:16 bauzas: no need for apologizing 16:36:10 is there anything else for today? 16:36:22 either way, my personal stake is that I'm okay to consider punting this feature from nova eventually, but we need a solid plan before selling it 16:36:37 totally agree ^^ 16:37:31 if no other topic today then 16:37:39 thanks for joing to the last meeting of 202 16:37:40 2020 16:37:46 and have a nice holiday period 16:37:56 I will be here tomorrow but then I'm only back on 4th of Jan 16:38:15 o/ 16:38:18 o/ 16:38:21 o/ 16:38:30 o/ 16:38:30 #endmeeting