16:00:05 <gibi> #startmeeting nova
16:00:06 <openstack> Meeting started Thu Nov 12 16:00:05 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:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:09 <openstack> The meeting name has been set to 'nova'
16:00:13 <lyarwood> \o
16:00:14 <stephenfin> o/
16:00:23 <dansmith> o/
16:00:26 <gibi> o/
16:00:56 <gibi> the openstack wallaby community call is happening in parallel. The project updates are pre-recorded so I try to be present on both meeting
16:01:36 <gibi> #topic Bugs (stuck/critical)
16:01:45 <gibi> no critical bugs
16:01:51 <gibi> #link 12 new untriaged bugs (+2 since the last meeting): #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
16:02:13 <gmann> o/
16:02:15 <gibi> #link 0 bugs in fix-commited state (-19 since last meeting): #link https://bugs.launchpad.net/nova/+bugs?field.searchtext=&search=Search&field.status%3Alist=FIXCOMMITTED
16:02:19 <gibi> I've moved all of these from fix-commmited to fix-released state.
16:02:39 <gibi> so I will drop this from the agenda, I don't expect new bugs will end up in this status in the future
16:03:05 <lyarwood> cool thanks gibi
16:03:05 <gibi> #link 73 bugs are in INPROGRESS state without any tag (+1 since the last meeting): #link https://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=INPROGRESS
16:03:19 <gibi> these are potentially un-triaged bugs. Check if they are still valid
16:04:12 <gibi> is there any bug we need to talk about here?
16:05:01 <gibi> #topic Gate status
16:05:10 <gibi> 69 (+54 since the last meeting) unclassified gate failures, classification rate 28% (-18 since the last meeting) #link http://status.openstack.org/elastic-recheck/data/integrated_gate.html
16:05:19 <gibi> Please look at the gate failures, file a bug, and add an elastic-recheck signature in the opendev/elastic-recheck repo (example: #link https://review.opendev.org/#/c/759967)
16:05:32 <gibi> I've filed one new today https://bugs.launchpad.net/nova/+bug/1903979
16:05:34 <openstack> Launchpad bug 1903979 in OpenStack Compute (nova) "nova-live-migration job fails during evacuate negative test" [High,Confirmed]
16:05:42 <stephenfin> I'm seeing a lot of "qemu monitor disconnected" errors in the nova-live-migrate jobs
16:05:53 <stephenfin> I assume those are already using Focal?
16:05:58 <lyarwood> stephenfin: during the actual live migration runs?
16:06:16 <lyarwood> stephenfin: and yeah it's switched over to focal now
16:06:20 <stephenfin> not totally sure - I'll check
16:06:26 <stephenfin> I think so though
16:06:35 <stephenfin> the test fails because the instance doesn't change host because the migration failed
16:07:08 <stephenfin> Also, https://review.opendev.org/762543 would be a good one to add to the review queues. I've seen that race pop up at least once recently
16:07:14 <lyarwood> stephenfin: kk lets ping kashyap
16:07:36 <stephenfin> will do
16:07:36 <gibi> stephenfin: queued the race fix now
16:07:39 <lyarwood> stephenfin: do you want to write a bug for that
16:07:45 <stephenfin> sure
16:07:48 <lyarwood> stephenfin: as I assume it applies to stable/victoria etc
16:07:54 <stephenfin> yup, fair point
16:08:02 <lyarwood> thanks
16:08:09 <gibi> thanks
16:08:12 * stephenfin hopes he can find the original failure to reference :)
16:08:41 <gibi> any other gate failures that needs discussion
16:08:42 <gibi> ?
16:09:28 <gibi> #topic Release Planning
16:09:43 <gibi> Wallaby Milestone 1 is on 3rd of December, which is 3 weeks from now
16:09:49 <gibi> We should focus on updating / reviewing spec based on the PTG discussions
16:09:53 <gibi> I proposed a spec review day on the ML for 17th of November (Tuesday): #link http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018564.html
16:10:51 <gibi> any other info related to the release?
16:11:06 <tbarron> Is the deadline for merge of specs Milestone 1?  (Don't see that on the Wallaby releae calendar).
16:11:19 <gibi> tbarron: spec freeze is M2
16:11:25 <tbarron> gibi: ty
16:11:46 <gibi> tbarron: https://wiki.openstack.org/wiki/Nova/Wallaby_Release_Schedule
16:12:11 <tbarron> gibi: ty, i was looking at the wrong calendar
16:12:19 <tbarron> the global one
16:12:49 <gibi> yeah, I guess there is a way to add nova specific things there
16:13:18 <tbarron> gibi: manila litters that one, no opinion on my part as to how you do it
16:13:26 <tbarron> this is bookmarked now
16:13:32 <gibi> OK, cool
16:13:37 <gibi> #topic Stable Branches
16:13:48 <gibi> elod left comments on the wiki I will copy now
16:13:55 <gibi> final Stein release is done (19.3.2) -- stein-em tagging is on the way: https://review.opendev.org/#/c/762408/
16:14:07 <gibi> new versions on Train (20.4.1), Ussuri (21.1.1) also released, Victoria release is still waiting for upgrade fix patch to merge (https://review.opendev.org/#/c/761639/ -- any other must-have for Victoria release?)
16:14:24 <gibi> EOM
16:14:39 <lyarwood> I don't have anything, elod++ for pushing all of that along :)
16:14:53 <gibi> thanks elod
16:14:54 <elod> lyarwood: ack :)
16:15:09 <gibi> I don't have other than the already tracked https://review.opendev.org/#/c/761639/ for victoria
16:16:33 <gibi> #topic Sub/related team Highlights
16:16:40 <gibi> API (gmann)
16:17:00 <gmann> nothing from my side on API
16:17:18 <gibi> Libvirt (bauzas)
16:19:17 <gibi> I guess he is not with us today
16:19:18 <gibi> #topic Open discussion
16:19:29 <gibi> there is an time from stephenfin on the agenda
16:19:37 <gibi> (stephenfin) Specless blueprint approval. Support for virtio-based input devices https://review.opendev.org/#/c/756552/
16:19:43 <gibi> Identified while trying to remove unnecessary USB interfaces for realtime
16:19:50 <gibi> We already support virtio-based disk and network interfaces. They're higher performance and their use can remove the need for a USB controller.
16:20:38 <gibi> is there any objection to approve this as specless?
16:21:01 <gibi> stephenfin: I guess you haven't filed the bp yet
16:21:01 <lyarwood> None from me.
16:21:17 <stephenfin> oh, damn, no. two secs :)
16:22:09 <gibi> stephenfin: no worries, ping me later when you have the link
16:22:22 <stephenfin> https://blueprints.launchpad.net/nova/+spec/virtio-based-input-devices
16:22:43 <dansmith> what's the trigger, config or flavor?
16:22:49 <stephenfin> image metadata
16:22:58 <stephenfin> to mimic what we do for e.g. disk buses
16:23:03 <dansmith> er, yeah, so a new key there akin do the disk controller?
16:23:03 <dansmith> yeah
16:23:08 <stephenfin> yarp
16:23:08 <stephenfin> hw_input_bus
16:23:16 <dansmith> seems straightforward to me
16:23:34 <gibi> looks good to me too
16:24:11 <gibi> no objectsion so it is approved for W
16:24:17 <dansmith> do we always do usb tablet now?
16:24:23 <dansmith> or are you going to make it ps2|usb|virtio?
16:24:33 <stephenfin> by default, yes
16:24:49 <stephenfin> though devstack overrides that default
16:24:54 <dansmith> don't we have a way to do ps2 tho?
16:25:09 <stephenfin> not on a per-instance basis
16:25:11 <dansmith> I was thinking that was config, hence my question about how we're triggering
16:25:20 <stephenfin> it's host-level config
16:25:23 <dansmith> yeah,
16:25:31 <stephenfin> [compute] point_model = ps2mouse
16:25:41 <dansmith> so do we need to deprecate/remove that config or what's the interaction between that and the metadata trigger?
16:25:57 <dansmith> always prefer image if the image specifies?
16:26:38 <stephenfin> I'm doing the latter
16:26:56 <stephenfin> and I'd like to deprecate the host-level config eventually, but I think we should let this bake in
16:27:06 <dansmith> oh, we already have hw_pointer_model
16:27:19 <dansmith> can we not just add virtio to that?
16:27:41 <stephenfin> No really. That currently munges two things: type of input device and bus used
16:27:44 <stephenfin> *not
16:27:57 <stephenfin> type being pointer or tablet; bus being ps2, usb or virtio
16:28:19 <dansmith> well, it's either ps2mouse (bus=ps2) or usbtablet (bus=tablet)
16:28:26 <dansmith> are you going to have both mouse and tablet via virtio?
16:28:52 <stephenfin> I thought that would be the most sensible approach
16:29:03 <stephenfin> hw_pointer_model = (mouse|tablet)
16:29:09 <stephenfin> hw_input_bus = (usb|virtio)
16:29:29 <stephenfin> I have an open question about whether we want to support ps2 that way, given its legacy, x86-only nature
16:29:30 <dansmith> is that what hw_pointer_model takes now? that differs from the config
16:29:55 <stephenfin> it currently only takes usbtablet
16:30:05 <dansmith> well, I'm just trying to figure out what the set of options are, given we have the config, the existing pointer key and the new bus
16:30:25 <dansmith> right, so, I guess I don't really see why we wouldn't just add virtiotablet in there and call it done
16:30:42 <dansmith> there's really no reason to have relative movement except for compatibility, which virtio does away with anyway
16:30:52 <stephenfin> hw_pointer_model=usbtablet will be translated to hw_pointer_model=tablet and hw_input_bus=tablet
16:31:31 <dansmith> and we have to validate/reject if someone configures pointer=usbtablet and bus=virtio ...
16:31:39 <stephenfin> I've no serious issues with that. Separate config made more sense to me, but keeping the munging also works
16:32:07 <stephenfin> Yup, we would
16:32:17 <stephenfin> (I've already done just that, fwiw https://review.opendev.org/#/c/756552/3/nova/virt/libvirt/driver.py)
16:32:31 <dansmith> there's just a flow chart involved in explaining all the options if you expand it out, plus the validation... if you just add one more option there with virtiotablet then it's much simpler, IMHO
16:32:54 <stephenfin> oh, wait
16:32:55 <dansmith> that validation happens very late though
16:33:01 <stephenfin> I know why I did separate buses
16:33:04 <stephenfin> we also have keyboards
16:33:22 <stephenfin> so you want some way to say what the bus for that is
16:33:43 <dansmith> but certainly not different busses for each right?
16:33:52 <stephenfin> no
16:33:57 <stephenfin> hw_input_bus handles both
16:34:15 <dansmith> ...so you can just assume whatever pointer method is being used is also used for the keyboard right?
16:34:37 <dansmith> i.e. usbtablet means usb keyboard, virtiotablet means virtio keyboard
16:35:06 <stephenfin> you could, but that's a lot of extrapolation and poor UX. I'd rather default to pointer model to tablet if the input bus was set to USB or virtio
16:35:47 <stephenfin> I mean, if we're going with "doing X also results in Y"-type behavior
16:35:55 <dansmith> well, adding a new key to expand the surface area and checking super late in virt config and just exploding there if it's wrong really isn't good UX
16:36:30 <stephenfin> True. That's already a risk though
16:36:34 <dansmith> and "virtiotablet" doesn't offer the possibility to ask for a virtio mouse, which is also good in that it doesn't lead people to make dumb decisions just because you can configure it that way
16:36:40 <stephenfin> We don't know that the hypervisor supports a specific bus
16:36:51 <stephenfin> Including virtio
16:37:10 <dansmith> sure, but the number of ways to configure an invalid thing is far fewer
16:37:25 <stephenfin> True
16:37:32 <stephenfin> Can we continue this on openstack-nova?
16:37:34 <dansmith> anyway, nobody else seems to care about this, so we don't need to make them watch
16:37:36 <dansmith> heh, yes
16:37:40 <stephenfin> cool :)
16:37:41 <gibi> :)
16:37:59 <gibi> OK, then I will keep the bp pending so you can agree on this question
16:38:06 <gibi> but when you agreed the bp will be approved
16:38:16 <gibi> I have one more item
16:38:19 <stephenfin> Well, the idea is okay? It's just how we implement it that's up for debate?
16:38:25 <dansmith> no need to hold it up, IMHO, just approve it and we can change the text if need be
16:38:29 <dansmith> yeah ^
16:38:59 <gibi> dansmith, stephenfin: OK then I will approve it after the meeting
16:39:07 <stephenfin> thanks
16:39:33 <gibi> so my item is http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018663.html
16:39:54 <gibi> this is the patch that breaks the nova-compute if DB is configured
16:40:06 <gibi> it seems there are additional things falling out from it
16:40:31 <gibi> 1) the packaging and deployer tools asking for information about which config is needed for which service
16:40:49 <gibi> I don't think we have definit information about this
16:41:19 <stephenfin> to do 1) properly, we'd need to rework how we gather config opts
16:41:35 <gibi> yeah, this is not easy to automate
16:41:42 <dansmith> we don't have to automate it
16:41:56 <dansmith> because we don't need (IMHO) to do it for every one of our billion opts
16:42:01 <dansmith> we could make things much better,
16:42:06 <gmann> is doc not enough for that ?
16:42:15 <dansmith> if we identified a minimal set of configs that have to be set to have a working nova,
16:42:24 <dansmith> and then annotate those with where they need to be set
16:42:42 <dansmith> it won't fix the world, but it would make things quite a bit better, and the deployment tools are mostly concerned with minimal config I think
16:43:16 <gibi> and I guess devstack does the minimal set already
16:43:21 <dansmith> database, api database, transport_url, etc.. make sure the docs for those configs are clear about which service needs them
16:43:23 <dansmith> yes
16:43:40 <dansmith> presumably we could also ask deployment tools for a set of configs they always set
16:43:41 <gibi> then I will file doc bug to document this based on devstack
16:43:48 <gmann> we can divide the doc section with mandatory vs optional
16:43:50 <stephenfin> The proper answer is to do what (I think) glance etc. do and register different opts to different namespaces. Most 'nova.conf.*' modules expose 'register_opts' and 'register_console_opts' functions; ideally we'd have 'register_compute_opts', 'register_scheduler_opts', etc. That's a whole pile of work though
16:43:56 <dansmith> but devstack should be the reference
16:44:11 <gmann> we had same question many times in tempest also when we had ~300 config opt
16:44:15 <stephenfin> dansmith: when you say annotate, do you mean add a new attribute or include in opt help strings?
16:44:20 <stephenfin> *include info
16:44:20 <dansmith> stephenfin: it is, and IMHO, the glance situation really sucks
16:44:40 <dansmith> stephenfin: I mean just a pattern like "related opts" or whatever we do now for linking related things..
16:45:25 <stephenfin> dansmith: Yeah, as someone who usually likes this kind of work, narp on this. Reworking the config last time took forever and we'd OSIC peeps to help /o\
16:45:36 <stephenfin> hmm, I can't picture that
16:45:40 <dansmith> stephenfin: narp on which?
16:45:53 <stephenfin> sorry, narp on doing service-based opt registration
16:45:57 <stephenfin> the big rework idea
16:46:06 <gmann> or we can make all optional as default to None always ? and code assume None means not set/configured?
16:46:12 <stephenfin> yes to annotation, once I figure out how that works
16:46:28 <dansmith> stephenfin: I mean this: https://pastebin.com/czCwqquw
16:46:44 <dansmith> stephenfin: for the <20 options that are really required for things to work
16:46:45 <gibi> gmann: without db and amqp config services will fail to start
16:46:54 <stephenfin> Ah, yes. That makes sense to me
16:47:07 <dansmith> stephenfin: yes, very very narp on service-based opts from me too
16:47:15 <gmann> gibi: yeah i mean that is mandatory opt so need to be set. so no default for them
16:47:18 * dansmith doesn't know what narps are but assumes they can be different sizes
16:47:31 <stephenfin> dansmith: https://www.youtube.com/watch?v=ir1sVy9JLyo
16:47:57 <gibi> I will file a bug based on the above and see where we can go with it
16:48:07 <gibi> there is another fallout
16:48:24 <gibi> for wsgi services we predefine the config file the wsgi app will load
16:48:37 <gibi> and for nova-api it is nova.conf and api_paste.ini
16:49:00 <gibi> as far as I understand this means that another config cannot be provided like nova-db.conf
16:49:14 <dansmith> this is really not our problem, IMHO
16:49:34 <stephenfin> gibi: Can we not invert this like devstack does
16:49:38 <dansmith> if you're doing this all-in-one, then configure nova-compute to load /etc/nova/nova-cpu.conf or something just like devstack does
16:49:40 <stephenfin> nova.conf for everything != nova-compute
16:49:44 <dansmith> exactly
16:49:44 <stephenfin> nova-cpu.conf for nova-compute
16:49:46 <stephenfin> yup
16:49:56 <gibi> yeah that works
16:49:58 <gmann> yeah
16:50:00 <dansmith> this is a deployment thing.. all deployments can copy files
16:50:23 <gmann> we can add devstack way as ref link in doc.
16:50:27 <stephenfin> Good enough for DevStack, good enough for me (TM)
16:50:58 <gibi> OK, I don't have anything else for this topic
16:51:16 <gibi> any other topics for today?
16:51:47 <dansmith> narp?
16:51:56 <gibi> narp :)
16:52:01 <gibi> thanks for joining
16:52:02 <stephenfin> got it in one
16:52:20 <gibi> stephenfin: ?
16:52:31 <stephenfin> nvm :) nothing from me
16:52:33 <gibi> OK
16:52:34 <gibi> cool
16:52:37 <gibi> #endmeeting