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