16:00:06 <gibi> #startmeeting nova
16:00:07 <openstack> Meeting started Thu Jan 21 16:00:06 2021 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:11 <openstack> The meeting name has been set to 'nova'
16:00:20 <lyarwood> \o
16:00:32 <dansmith> o/
16:00:36 <stephenfin> o/
16:01:10 <gibi> o/
16:01:31 <bauzas> \o
16:01:32 <gibi> #topic Bugs (stuck/critical)
16:01:44 <gibi> we have one critical bug #link https://bugs.launchpad.net/nova/+bug/1912607
16:01:46 <openstack> Launchpad bug 1912607 in OpenStack Compute (nova) "test_attach_cloned_encrypted_volume fails in nova-ceph-multistore job permanently " [Critical,In progress] - Assigned to Lee Yarwood (lyarwood)
16:01:58 <gibi> there is a patch to fix it #link https://review.opendev.org/c/openstack/nova/+/771777
16:02:07 <dansmith> ++
16:02:08 <gibi> but I saw some dicussion on #openstack-nova
16:02:11 <gmann> o/
16:02:20 <gibi> dansmith, lyarwood does ^^ enough?
16:02:25 <lyarwood> gibi: yeah that's enough
16:02:27 <dansmith> yup
16:02:31 <gibi> cool
16:02:32 <lyarwood> gibi: I'm going to try to clean things up after
16:02:37 <gibi> lyarwood: thanks
16:02:38 <lyarwood> gibi: but for now that's all we needd
16:03:06 <gibi> is there any other bug we need to dicuss today?
16:03:21 <gibi> btw #link 18 new untriaged bugs (+2 since the last meeting): #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
16:04:09 <gibi> #topic Gate status
16:04:13 <gibi> gate on master is blocked due to #link https://bugs.launchpad.net/nova/+bug/1912607
16:04:14 <openstack> Launchpad bug 1912607 in OpenStack Compute (nova) "test_attach_cloned_encrypted_volume fails in nova-ceph-multistore job permanently " [Critical,In progress] - Assigned to Lee Yarwood (lyarwood)
16:04:23 <gibi> is there any other gate issue we should be aware of?
16:04:55 <lyarwood> I've seen https://bugs.launchpad.net/nova/+bug/1912310 crop up a few times in the last week
16:04:56 <openstack> Launchpad bug 1912310 in OpenStack Compute (nova) "libvirt.libvirtError: unable to connect to server at " [Undecided,New]
16:05:07 <lyarwood> in the live migration jobs, yet to debug any further
16:06:20 <gibi> thanks for the headsup
16:07:08 <gibi> #topic Release Planning
16:07:14 <gibi> today is Milestone 2
16:07:22 <gibi> We have spec freeze today. Spec that does not have two +2s at EOB today will need to be moved to X
16:08:02 <gibi> We have 14 approved bp and we completed 1 so far.
16:08:14 <gibi> is there any open spec that needs special attention?
16:08:58 <gibi> I see https://review.opendev.org/c/openstack/nova-specs/+/765901 being close
16:09:08 <gibi> add port scoped numa affinity spec ^^
16:09:56 <gibi> there is an open issue on it conserning the precedence order of the policy in the port and in the flavor
16:10:09 <gibi> so it needs more eyes today, or it will be bumped to X
16:11:19 <gibi> any other M2 or release related topic to discuss?
16:12:56 <gibi> #topic Runway status
16:13:02 <gibi> #link https://etherpad.opendev.org/p/nova-runways-wallaby
16:13:03 <sean-k-mooney> i put that in the opens discsuion section by the way
16:13:15 <sean-k-mooney> but ya we can move on
16:13:16 <gibi> sean-k-mooney: OK, then we can go back to that
16:13:23 <gibi> in the open discussion
16:13:31 <gibi> so runways
16:13:45 <gibi> #link https://blueprints.launchpad.net/nova/+spec/cyborg-shelve-and-unshelve  : has been completed \o/
16:13:54 <gibi> #link https://blueprints.launchpad.net/nova/+spec/nova-support-webvnc-with-password-anthentication : has been updated and needs re-review
16:14:20 <gibi> I will do a review round on it as I had reviewed it previously
16:14:34 <gibi> #link https://blueprints.launchpad.net/nova/+spec/compact-db-migrations-wallaby : first half of the patches has been merged, the rest needs a second core to approve
16:15:23 <dansmith> I +2d all of them,
16:15:25 <gibi> I guess we will eat these patches slowly but surely I see dansmith and bauzas is being involved
16:15:26 <dansmith> I thought you did too
16:15:28 <dansmith> did you mean a third?
16:15:39 <gibi> hm, I can go back and upgrade my votes
16:15:40 <bauzas> gibi: I'll continue
16:15:48 <gibi> but it is better to have a third eye
16:15:49 <gibi> bauzas: thanks
16:15:56 <bauzas> but this takes a bit of time
16:16:02 <gibi> bauzas: sure it is
16:16:04 <bauzas> and I'm conservative about DB changes
16:16:22 <dansmith> as we all should be :)
16:16:27 <gibi> agree
16:16:42 <gibi> #link https://blueprints.launchpad.net/nova/+spec/modernize-os-hypervisors-api : the api code landed, the python-novaclient patch and the policy patch needs some work
16:17:09 <bauzas> I totally forgot to look at the series
16:17:19 <gibi> as far as I see the ball is at stephenfin's side in the open patches
16:17:41 <stephenfin> yup, gotta respin those
16:17:49 <gibi> cool
16:18:00 <gibi> and last but no least :)
16:18:00 <gibi> #link https://blueprints.launchpad.net/nova/+spec/support-interface-attach-with-qos-ports : stephenfin is +2 all over it, so it needs a second core to look at
16:19:16 <bauzas> I can do it
16:19:18 <gibi> I can trade reviews with any cores if needed
16:19:20 * bauzas clicks
16:19:25 <gibi> bauzas: thanks
16:19:58 <gibi> anything else related almost-done features?
16:20:58 <sean-k-mooney> gibi: i was +1 on that in the past too right
16:21:08 <gibi> sean-k-mooney: yes I think so
16:21:23 <sean-k-mooney> i am +1 on qos attach in general so it would be nice ot see that approved
16:21:53 <sean-k-mooney> oh the spec is approved
16:22:07 <gibi> sean-k-mooney: yeah this was about the implementation :) which is also quite ready
16:22:10 <sean-k-mooney> ill try and reveiw the  code today
16:22:14 <gibi> thanks
16:22:22 <gibi> #topic Stable Branches
16:22:30 <gibi> only stable/rocky is blocked (patch to unblock: https://review.opendev.org/766492 )
16:22:35 <gibi> the rest looks OK
16:22:38 <gibi> EOM
16:22:50 <gibi> any other stable thing to bring up?
16:23:09 <elod> meanwhile that patch is +2+W'd by lyarwood , thx for that!
16:23:16 <elod> nothing else I think
16:23:17 <lyarwood> yup that's all I had
16:23:17 <gibi> cool
16:23:24 <gibi> #topic Sub/related team Highlights
16:23:28 <gibi> Libvirt (bauzas)
16:23:37 <bauzas> nothing to report, sir.
16:23:42 <gibi> OK
16:23:47 <lyarwood> version bump is posted
16:24:01 <gibi> lyarwood: I will review that in the coming days
16:24:03 <lyarwood> we also have a few changes dropping UML and Xen if anyone has time
16:24:21 <lyarwood> https://review.opendev.org/c/openstack/nova/+/754700
16:25:49 <gibi> #topic Open discussion
16:25:57 <gibi> (stephenfin) Approve specless blueprint https://blueprints.launchpad.net/nova/+spec/smarter-usb-devices
16:26:01 <gibi> The name is misleading. This is both a bugfix (don't add USB controllers unless needed, which is already merged) and add support for a 'hw_input_bus' image metadata property
16:26:09 <gibi> This was already discussed previously. melwitt was ambivalent and deferred to others http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018713.html
16:26:54 <gibi> also impl patches are available https://review.opendev.org/q/topic:bp/smarter-usb-devices
16:27:08 <stephenfin> I think that summarizes it quite nicely. Just checking that no one is against me continuing with that
16:27:32 <gibi> any objections?
16:28:38 <sean-k-mooney> no just notig that the second half is not backporable
16:28:41 <sean-k-mooney> where as the first might be
16:28:47 <sean-k-mooney> so make sure they are in seperate patches
16:28:53 <stephenfin> yup, they are
16:29:11 <sean-k-mooney> cool
16:29:59 <gibi> I hear no objection so I will approve the bp after the meeting
16:30:14 <stephenfin> ta
16:30:16 <gibi> (sean) https://review.opendev.org/c/openstack/nova-specs/+/765901 precedence of port numa affinity policy
16:31:04 <gibi> so the numa affinity policy can be provided in the flavor
16:31:21 <gibi> and the spec proposes the possibility to provide it in the port as well
16:31:40 <gibi> the spec proposes also that the precedence is port > flavor
16:31:55 <gibi> which make sense from the perspective that the port is more fine grained
16:32:15 <gibi> and therefore allow customization of a flavor based policy
16:32:29 <gibi> but the flavor based policy is admin only by default
16:32:40 <gibi> while the port based policy is not admin only
16:32:53 <stephenfin> that seems a bit misleading
16:33:00 <gibi> stephenfin: correct me please
16:33:05 <stephenfin> it's admin-only because flavor extra specs are admin-only
16:33:05 <artom> We have the same policy in image meta as well, what's the preference there?
16:33:12 <artom> Seeing as image is user and flavor is admin...
16:33:26 <sean-k-mooney> if image != flavor then erorr
16:33:34 * bauzas drops \o
16:33:39 <gibi> bauzas: \o
16:33:52 <sean-k-mooney> other wise we use image or flavor with same precednce
16:33:57 <stephenfin> but there's no special reason we couldn't otherwise allow non-admins configure NUMA policies
16:33:57 <artom> sean-k-mooney, that seems... pointless? So if flavor doesn't have anything, image can't set it?
16:34:08 <sean-k-mooney> welll no
16:34:09 <stephenfin> artom: if the flavor is set
16:34:21 <stephenfin> if both are set and they don't match
16:34:45 <artom> stephenfin, so could we apply the same logic to port?
16:34:50 <stephenfin> (we've a bad history of flip-flopping on how to resolve image-flavour mismatches)
16:34:54 <artom> Only use it if flavor doesn't set anything?
16:35:14 <stephenfin> we could, but that would kill a certain amount of the value of the feature
16:35:16 <sean-k-mooney> if we do that you cant set a different polciy for alis based passthough
16:35:33 <stephenfin> you want to be able to say "all ports *except* this one have NUMA affinity*
16:35:37 <stephenfin> *"
16:35:44 <sean-k-mooney> that too
16:35:48 <stephenfin> as well as "all ports *except* this one don't have NUMA affinity"
16:36:07 <stephenfin> s/NUMA affinity/strict NUMA affinity/
16:36:11 <artom> If that's the use case I don't see how port can be anything other than "final word"
16:36:14 <sean-k-mooney> the extra specs also only applie to sriov/pci devices
16:36:22 <sean-k-mooney> its is ignored for numa aware vswitches
16:36:58 <sean-k-mooney> if that is configreued you have stict affintiy for all numa instnaces
16:37:01 <stephenfin> gibi: If there were a "negative" NUMA affinity policy then I'd agree that something user configurable (port policies) wouldn't be allowed override what the admin states
16:37:17 <stephenfin> because that would prevent the admin "preserving" resources
16:37:34 <stephenfin> but we don't provide that because it would be actively harmful :)
16:38:06 <artom> stephenfin, I guess the question could be - would there ever be a use case for an admin reserving a PCI device for a specific NUMA node?
16:38:24 <sean-k-mooney> you cant do that today
16:38:27 <gibi> stephenfin: so nova always prefer affinity regardless of the policy but doesn't fail if it cannot affine it if the policy allows suboptimal config
16:38:30 <stephenfin> artom: we don't provide any way to do that
16:38:49 <stephenfin> gibi: yes
16:38:55 <gibi> stephenfin: then you convinced me
16:39:04 <gibi> I'm OK with the currently proposed precedence
16:39:17 <sean-k-mooney> melwitt: thoughts?
16:39:18 <stephenfin> if the user insists on optimal config and we can't give it to them, well, that's on them
16:39:32 <artom> stephenfin, ok, re-phrasing - if the admin sets a `required` policy because for some reason they only want PCI devices to be used by VMs on the same NUMA nodes...
16:39:58 <artom> Would there ever be a use case where the user overriding that with a port policy would be harmful?
16:40:10 <sean-k-mooney> one thing that imporant here is the admins policy will still apply to all other ports and passthough devices
16:40:12 <stephenfin> artom: while possible, I don't think that's a realistic scenario
16:40:19 <sean-k-mooney> the policy on the port only applies to that port
16:40:27 <artom> stephenfin, I mean, I'd tend to agree - I'm playing devil's advocate here
16:40:27 <stephenfin> no, the user would just get worse performance
16:40:42 <stephenfin> oh yeah, I know :)
16:41:35 <gibi> getting worse performance when explicitly asked for is OK in my eyes
16:42:08 <stephenfin> yeah, and nova will already try to give better performance, so all the non-admin user could do is insist on it
16:42:09 <gibi> I will upgrade my vote on the spec but hold the +W so that melwitt can comment.
16:42:13 <sean-k-mooney> ya one usecase that dirves that is the nfv case where eveything should be strict but they dont care about the managment interface
16:42:18 <stephenfin> which would simply fail if it couldn't be met
16:42:30 <stephenfin> cool
16:42:52 <gibi> is there anything else for today?
16:43:10 <sean-k-mooney> not from me
16:43:34 <gibi> OK
16:43:46 <gibi> thanks for joining today. Enjoy the rest of your day!
16:44:08 <sean-k-mooney> o/
16:44:13 <gibi> #endmeeting