Thursday, 2020-11-12

*** macz_ has quit IRC01:15
*** mlavalle has quit IRC01:33
*** baojg has quit IRC01:42
*** baojg has joined #openstack-meeting-301:42
*** hongbin has joined #openstack-meeting-302:12
*** macz_ has joined #openstack-meeting-302:36
*** macz_ has quit IRC02:41
*** hongbin has quit IRC03:16
*** psachin has joined #openstack-meeting-303:27
*** macz_ has joined #openstack-meeting-304:25
*** macz_ has quit IRC04:30
*** ralonsoh has joined #openstack-meeting-307:23
*** slaweq has joined #openstack-meeting-307:29
*** lpetrut has joined #openstack-meeting-307:35
*** e0ne has joined #openstack-meeting-309:04
*** hongbin has joined #openstack-meeting-309:46
*** baojg has quit IRC10:16
*** hongbin has quit IRC10:36
*** hongbin has joined #openstack-meeting-310:37
*** baojg has joined #openstack-meeting-311:34
*** hongbin has quit IRC11:48
*** baojg has quit IRC12:07
*** baojg has joined #openstack-meeting-312:08
*** tosky has joined #openstack-meeting-312:18
*** artom has joined #openstack-meeting-312:54
*** macz_ has joined #openstack-meeting-313:30
*** macz_ has quit IRC13:35
*** Luzi has joined #openstack-meeting-313:44
*** Luzi has quit IRC14:32
*** artom has quit IRC14:37
*** artom has joined #openstack-meeting-314:37
*** lpetrut has quit IRC15:05
*** e0ne has quit IRC15:22
*** e0ne has joined #openstack-meeting-315:23
*** baojg has quit IRC15:35
*** baojg has joined #openstack-meeting-315:35
*** mlavalle has joined #openstack-meeting-315:54
*** lyarwood has joined #openstack-meeting-315:55
*** elod has joined #openstack-meeting-315:58
*** tbarron has joined #openstack-meeting-315:59
gibi#startmeeting nova16:00
openstackMeeting 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
*** openstack changes topic to " (Meeting topic: nova)"16:00
openstackThe meeting name has been set to 'nova'16:00
lyarwood\o16:00
stephenfino/16:00
dansmitho/16:00
gibio/16:00
gibithe openstack wallaby community call is happening in parallel. The project updates are pre-recorded so I try to be present on both meeting16:00
gibi#topic Bugs (stuck/critical)16:01
*** openstack changes topic to "Bugs (stuck/critical) (Meeting topic: nova)"16:01
gibino critical bugs16:01
gibi#link 12 new untriaged bugs (+2 since the last meeting): #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New16:01
gmanno/16:02
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=FIXCOMMITTED16:02
gibiI've moved all of these from fix-commmited to fix-released state.16:02
gibiso I will drop this from the agenda, I don't expect new bugs will end up in this status in the future16:02
lyarwoodcool thanks gibi16:03
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=INPROGRESS16:03
gibithese are potentially un-triaged bugs. Check if they are still valid16:03
*** macz_ has joined #openstack-meeting-316:03
gibiis there any bug we need to talk about here?16:04
gibi#topic Gate status16:05
*** openstack changes topic to "Gate status (Meeting topic: nova)"16:05
gibi69 (+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.html16:05
gibiPlease 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
gibiI've filed one new today https://bugs.launchpad.net/nova/+bug/190397916:05
openstackLaunchpad bug 1903979 in OpenStack Compute (nova) "nova-live-migration job fails during evacuate negative test" [High,Confirmed]16:05
stephenfinI'm seeing a lot of "qemu monitor disconnected" errors in the nova-live-migrate jobs16:05
stephenfinI assume those are already using Focal?16:05
lyarwoodstephenfin: during the actual live migration runs?16:05
lyarwoodstephenfin: and yeah it's switched over to focal now16:06
stephenfinnot totally sure - I'll check16:06
stephenfinI think so though16:06
stephenfinthe test fails because the instance doesn't change host because the migration failed16:06
stephenfinAlso, 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 recently16:07
lyarwoodstephenfin: kk lets ping kashyap16:07
stephenfinwill do16:07
gibistephenfin: queued the race fix now16:07
lyarwoodstephenfin: do you want to write a bug for that16:07
stephenfinsure16:07
lyarwoodstephenfin: as I assume it applies to stable/victoria etc16:07
stephenfinyup, fair point16:07
lyarwoodthanks16:08
gibithanks16:08
* stephenfin hopes he can find the original failure to reference :)16:08
*** macz_ has quit IRC16:08
gibiany other gate failures that needs discussion16:08
gibi?16:08
gibi#topic Release Planning16:09
*** openstack changes topic to "Release Planning (Meeting topic: nova)"16:09
gibiWallaby Milestone 1 is on 3rd of December, which is 3 weeks from now16:09
gibiWe should focus on updating / reviewing spec based on the PTG discussions16:09
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.html16:09
gibiany other info related to the release?16:10
tbarronIs the deadline for merge of specs Milestone 1?  (Don't see that on the Wallaby releae calendar).16:11
gibitbarron: spec freeze is M216:11
tbarrongibi: ty16:11
gibitbarron: https://wiki.openstack.org/wiki/Nova/Wallaby_Release_Schedule16:11
tbarrongibi: ty, i was looking at the wrong calendar16:12
tbarronthe global one16:12
*** macz_ has joined #openstack-meeting-316:12
*** macz_ has quit IRC16:12
gibiyeah, I guess there is a way to add nova specific things there16:12
tbarrongibi: manila litters that one, no opinion on my part as to how you do it16:13
*** macz_ has joined #openstack-meeting-316:13
tbarronthis is bookmarked now16:13
gibiOK, cool16:13
gibi#topic Stable Branches16:13
*** openstack changes topic to "Stable Branches (Meeting topic: nova)"16:13
gibielod left comments on the wiki I will copy now16:13
gibifinal Stein release is done (19.3.2) -- stein-em tagging is on the way: https://review.opendev.org/#/c/762408/16:13
gibinew 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
gibiEOM16:14
lyarwoodI don't have anything, elod++ for pushing all of that along :)16:14
gibithanks elod16:14
elodlyarwood: ack :)16:14
gibiI don't have other than the already tracked https://review.opendev.org/#/c/761639/ for victoria16:15
gibi#topic Sub/related team Highlights16:16
*** openstack changes topic to "Sub/related team Highlights (Meeting topic: nova)"16:16
gibiAPI (gmann)16:16
gmannnothing from my side on API16:17
gibiLibvirt (bauzas)16:17
gibiI guess he is not with us today16:19
gibi#topic Open discussion16:19
*** openstack changes topic to "Open discussion (Meeting topic: nova)"16:19
gibithere is an time from stephenfin on the agenda16:19
gibi(stephenfin) Specless blueprint approval. Support for virtio-based input devices https://review.opendev.org/#/c/756552/16:19
gibiIdentified while trying to remove unnecessary USB interfaces for realtime16:19
gibiWe already support virtio-based disk and network interfaces. They're higher performance and their use can remove the need for a USB controller.16:19
gibiis there any objection to approve this as specless?16:20
gibistephenfin: I guess you haven't filed the bp yet16:21
lyarwoodNone from me.16:21
stephenfinoh, damn, no. two secs :)16:21
gibistephenfin: no worries, ping me later when you have the link16:22
stephenfinhttps://blueprints.launchpad.net/nova/+spec/virtio-based-input-devices16:22
dansmithwhat's the trigger, config or flavor?16:22
stephenfinimage metadata16:22
stephenfinto mimic what we do for e.g. disk buses16:22
dansmither, yeah, so a new key there akin do the disk controller?16:23
dansmithyeah16:23
stephenfinyarp16:23
stephenfinhw_input_bus16:23
dansmithseems straightforward to me16:23
gibilooks good to me too16:23
*** e0ne has quit IRC16:23
gibino objectsion so it is approved for W16:24
*** e0ne has joined #openstack-meeting-316:24
dansmithdo we always do usb tablet now?16:24
dansmithor are you going to make it ps2|usb|virtio?16:24
*** e0ne has quit IRC16:24
stephenfinby default, yes16:24
stephenfinthough devstack overrides that default16:24
dansmithdon't we have a way to do ps2 tho?16:24
stephenfinnot on a per-instance basis16:25
dansmithI was thinking that was config, hence my question about how we're triggering16:25
stephenfinit's host-level config16:25
dansmithyeah,16:25
stephenfin[compute] point_model = ps2mouse16:25
dansmithso do we need to deprecate/remove that config or what's the interaction between that and the metadata trigger?16:25
dansmithalways prefer image if the image specifies?16:25
stephenfinI'm doing the latter16:26
stephenfinand I'd like to deprecate the host-level config eventually, but I think we should let this bake in16:26
dansmithoh, we already have hw_pointer_model16:27
dansmithcan we not just add virtio to that?16:27
stephenfinNo really. That currently munges two things: type of input device and bus used16:27
stephenfin*not16:27
stephenfintype being pointer or tablet; bus being ps2, usb or virtio16:27
dansmithwell, it's either ps2mouse (bus=ps2) or usbtablet (bus=tablet)16:28
dansmithare you going to have both mouse and tablet via virtio?16:28
stephenfinI thought that would be the most sensible approach16:28
stephenfinhw_pointer_model = (mouse|tablet)16:29
stephenfinhw_input_bus = (usb|virtio)16:29
stephenfinI have an open question about whether we want to support ps2 that way, given its legacy, x86-only nature16:29
dansmithis that what hw_pointer_model takes now? that differs from the config16:29
stephenfinit currently only takes usbtablet16:29
dansmithwell, 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 bus16:30
dansmithright, so, I guess I don't really see why we wouldn't just add virtiotablet in there and call it done16:30
dansmiththere's really no reason to have relative movement except for compatibility, which virtio does away with anyway16:30
stephenfinhw_pointer_model=usbtablet will be translated to hw_pointer_model=tablet and hw_input_bus=tablet16:30
*** elod has quit IRC16:31
dansmithand we have to validate/reject if someone configures pointer=usbtablet and bus=virtio ...16:31
stephenfinI've no serious issues with that. Separate config made more sense to me, but keeping the munging also works16:31
stephenfinYup, we would16:32
stephenfin(I've already done just that, fwiw https://review.opendev.org/#/c/756552/3/nova/virt/libvirt/driver.py)16:32
dansmiththere'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, IMHO16:32
*** elod has joined #openstack-meeting-316:32
stephenfinoh, wait16:32
dansmiththat validation happens very late though16:32
stephenfinI know why I did separate buses16:33
stephenfinwe also have keyboards16:33
stephenfinso you want some way to say what the bus for that is16:33
dansmithbut certainly not different busses for each right?16:33
stephenfinno16:33
stephenfinhw_input_bus handles both16:33
dansmith...so you can just assume whatever pointer method is being used is also used for the keyboard right?16:34
dansmithi.e. usbtablet means usb keyboard, virtiotablet means virtio keyboard16:34
stephenfinyou 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 virtio16:35
stephenfinI mean, if we're going with "doing X also results in Y"-type behavior16:35
dansmithwell, 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 UX16:35
stephenfinTrue. That's already a risk though16:36
dansmithand "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 way16:36
stephenfinWe don't know that the hypervisor supports a specific bus16:36
stephenfinIncluding virtio16:36
dansmithsure, but the number of ways to configure an invalid thing is far fewer16:37
stephenfinTrue16:37
stephenfinCan we continue this on openstack-nova?16:37
dansmithanyway, nobody else seems to care about this, so we don't need to make them watch16:37
dansmithheh, yes16:37
stephenfincool :)16:37
gibi:)16:37
gibiOK, then I will keep the bp pending so you can agree on this question16:37
gibibut when you agreed the bp will be approved16:38
gibiI have one more item16:38
stephenfinWell, the idea is okay? It's just how we implement it that's up for debate?16:38
dansmithno need to hold it up, IMHO, just approve it and we can change the text if need be16:38
dansmithyeah ^16:38
gibidansmith, stephenfin: OK then I will approve it after the meeting16:38
stephenfinthanks16:39
gibiso my item is http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018663.html16:39
gibithis is the patch that breaks the nova-compute if DB is configured16:39
gibiit seems there are additional things falling out from it16:40
gibi1) the packaging and deployer tools asking for information about which config is needed for which service16:40
gibiI don't think we have definit information about this16:40
stephenfinto do 1) properly, we'd need to rework how we gather config opts16:41
gibiyeah, this is not easy to automate16:41
dansmithwe don't have to automate it16:41
dansmithbecause we don't need (IMHO) to do it for every one of our billion opts16:41
dansmithwe could make things much better,16:42
gmannis doc not enough for that ?16:42
dansmithif we identified a minimal set of configs that have to be set to have a working nova,16:42
dansmithand then annotate those with where they need to be set16:42
dansmithit 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 think16:42
gibiand I guess devstack does the minimal set already16:43
dansmithdatabase, api database, transport_url, etc.. make sure the docs for those configs are clear about which service needs them16:43
dansmithyes16:43
dansmithpresumably we could also ask deployment tools for a set of configs they always set16:43
gibithen I will file doc bug to document this based on devstack16:43
gmannwe can divide the doc section with mandatory vs optional16:43
stephenfinThe 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 though16:43
dansmithbut devstack should be the reference16:43
gmannwe had same question many times in tempest also when we had ~300 config opt16:44
stephenfindansmith: when you say annotate, do you mean add a new attribute or include in opt help strings?16:44
stephenfin*include info16:44
dansmithstephenfin: it is, and IMHO, the glance situation really sucks16:44
dansmithstephenfin: I mean just a pattern like "related opts" or whatever we do now for linking related things..16:44
stephenfindansmith: 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
stephenfinhmm, I can't picture that16:45
dansmithstephenfin: narp on which?16:45
stephenfinsorry, narp on doing service-based opt registration16:45
stephenfinthe big rework idea16:45
gmannor we can make all optional as default to None always ? and code assume None means not set/configured?16:46
stephenfinyes to annotation, once I figure out how that works16:46
dansmithstephenfin: I mean this: https://pastebin.com/czCwqquw16:46
dansmithstephenfin: for the <20 options that are really required for things to work16:46
gibigmann: without db and amqp config services will fail to start16:46
stephenfinAh, yes. That makes sense to me16:46
dansmithstephenfin: yes, very very narp on service-based opts from me too16:47
gmanngibi: yeah i mean that is mandatory opt so need to be set. so no default for them16:47
* dansmith doesn't know what narps are but assumes they can be different sizes16:47
stephenfindansmith: https://www.youtube.com/watch?v=ir1sVy9JLyo16:47
gibiI will file a bug based on the above and see where we can go with it16:47
gibithere is another fallout16:48
gibifor wsgi services we predefine the config file the wsgi app will load16:48
gibiand for nova-api it is nova.conf and api_paste.ini16:48
gibias far as I understand this means that another config cannot be provided like nova-db.conf16:49
dansmiththis is really not our problem, IMHO16:49
stephenfingibi: Can we not invert this like devstack does16:49
dansmithif you're doing this all-in-one, then configure nova-compute to load /etc/nova/nova-cpu.conf or something just like devstack does16:49
stephenfinnova.conf for everything != nova-compute16:49
dansmithexactly16:49
stephenfinnova-cpu.conf for nova-compute16:49
stephenfinyup16:49
gibiyeah that works16:49
gmannyeah16:49
dansmiththis is a deployment thing.. all deployments can copy files16:50
gmannwe can add devstack way as ref link in doc.16:50
stephenfinGood enough for DevStack, good enough for me (TM)16:50
gibiOK, I don't have anything else for this topic16:50
gibiany other topics for today?16:51
dansmithnarp?16:51
gibinarp :)16:51
gibithanks for joining16:52
stephenfingot it in one16:52
gibistephenfin: ?16:52
stephenfinnvm :) nothing from me16:52
gibiOK16:52
gibicool16:52
gibi#endmeeting16:52
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings/"16:52
openstackMeeting ended Thu Nov 12 16:52:37 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:52
openstackMinutes:        http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-11-12-16.00.html16:52
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-11-12-16.00.txt16:52
openstackLog:            http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-11-12-16.00.log.html16:52
*** elod has left #openstack-meeting-316:59
*** baojg has quit IRC18:13
*** baojg has joined #openstack-meeting-318:14
*** psachin has quit IRC18:28
*** ralonsoh has quit IRC18:44
*** baojg has quit IRC19:20
*** baojg has joined #openstack-meeting-319:21
*** baojg has quit IRC19:30
*** baojg has joined #openstack-meeting-319:31
*** artom has quit IRC21:15
*** slaweq has quit IRC21:30
*** slaweq has joined #openstack-meeting-321:33
*** slaweq has quit IRC21:41
*** raildo has quit IRC22:07
*** persia has quit IRC22:31
*** persia has joined #openstack-meeting-322:32
*** tosky has quit IRC22:44
*** _mlavalle_1 has joined #openstack-meeting-323:21
*** baojg has quit IRC23:23
*** lyarwood has quit IRC23:23
*** lyarwood has joined #openstack-meeting-323:24
*** mlavalle has quit IRC23:24
*** baojg has joined #openstack-meeting-323:26

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!