Earlier  
Posted Nick Remark
#openstack-nova - 2019-09-24
14:26:10 sean-k-mooney it defualt to stict in numatune because if you said you want to tune the numa memory it makes sense to default to strict
14:26:24 sean-k-mooney given by default numa tune is not used and no tuning is used
14:26:50 sean-k-mooney so you are already opting into affinty by generating the numatune elements
14:26:58 KeithMnemonic mriedem yes there is an issue? or yes i can try and backport it ?
14:27:15 mriedem KeithMnemonic: you basically asked if it's ok to backport something from train that removed something that was deprecated in stein, and has nothing to do with rocky
14:27:32 mriedem i know suse is super in love with rocky
14:27:35 mriedem but...
14:28:01 kashyap sean-k-mooney: I'm NUMA-unaware, so afraid, I still can't parse _why_ libvirt defaults to 'strict'
14:28:17 kashyap (Or weakly-aware)
14:28:33 KeithMnemonic oh i see, filters were deprecated in stein
14:28:39 kashyap sean-k-mooney: Please rephrase, if you can...
14:28:42 KeithMnemonic https://review.opendev.org/#/c/596502/
14:28:57 mriedem correct
14:28:59 sean-k-mooney kashyap: by default you do not specify numatune elements. so by defualt libvirt does not enforce strict affinity
14:29:01 KeithMnemonic so at a minimum it would make sense to put this to stein as well if someone needed it?
14:29:09 kashyap sean-k-mooney: Aah, like that!
14:29:37 mriedem KeithMnemonic: put what? https://review.opendev.org/#/c/551026/ in stein?
14:29:40 sean-k-mooney kashyap: when you therefor add the numatune element it makes sense for it to default to strcit since you ar opting out of the default behavior of no tuneing
14:30:07 sean-k-mooney kashyap: does that make sense?
14:30:19 mriedem KeithMnemonic: https://review.opendev.org/#/c/551026/ depends on https://review.opendev.org/#/c/672065/ which you can't backport to stein
14:30:20 kashyap sean-k-mooney: Yes, that's clearer. Thank you
14:30:27 KeithMnemonic got it
14:30:28 mriedem you can't say "x is deprecated and also removed in the same release"
14:30:31 mriedem maybe suse can
14:30:32 KeithMnemonic thanks for cleating it up
14:30:36 mriedem but that's a pretty bad precedent
14:30:41 KeithMnemonic no we dont
14:31:21 KeithMnemonic just a customer complaining about the root issue https://bugs.launchpad.net/nova/+bug/1469179 and see what options there are
14:31:21 openstack Launchpad bug 1469179 in OpenStack Compute (nova) "instance.root_gb should be 0 for volume-backed instances" [Medium,Fix released] - Assigned to Dan Smith (danms)
14:32:03 sean-k-mooney KeithMnemonic: thy can change there flavor to have 0 root disk
14:32:44 mriedem KeithMnemonic: the main fix was in rocky https://review.opendev.org/#/c/580720/
14:32:47 KeithMnemonic yup, that is the workaround they have in place
14:33:00 mriedem the DiskFilter should be disabled (since pike i think)
14:33:17 sean-k-mooney mriedem: yes it should
14:33:36 KeithMnemonic but some sales guy saw the launchpad bug and is asking why it was not fully fixed in rocky. and thanks to mriedem i can answer now ;-)
14:34:52 mriedem it is fixed in rocky
14:35:27 sean-k-mooney did we add the policy rule in rocky too? i think we did but its deisable by defualt?
14:35:54 mriedem yes https://docs.openstack.org/nova/rocky/configuration/policy.html
14:35:58 mriedem os_compute_api:servers:create:zero_disk_flavor
14:39:08 sean-k-mooney so the rocky fix is 1.) disable ram|cpu|disk filters 2.) create bfv 0 disk flavors, 3.) chage the os_compute_api:servers:create:zero_disk_flavor rule to rule:admin_api
14:40:15 mriedem it depends on what you care about,
14:40:48 mriedem the immediate issue is failing scheduling b/c of the DiskFilter or claim (by having DiskFilter enabled) and booting a volume-backed server - that is fixed with dan's fix above and disabling the DiskFilter since placement won't filter on DISK_GB
14:41:10 mriedem the resource tracker should also not be counting volume-backed server usage against the compute node (hypervisors API) since rocky
14:41:27 mriedem so i'm not sure what is *not* fixed in rocky
14:42:34 sean-k-mooney right. the only thing i can think of is that we dont default to safe regarding os_compute_api:servers:create:zero_disk_flavor
14:42:46 sean-k-mooney but that is for backwards comaptablity in rocky
14:56:01 openstackgerrit Merged openstack/os-resource-classes master: Update bug link in docs to point to storyboard https://review.opendev.org/681464
15:02:09 openstackgerrit Artom Lifshitz proposed openstack/nova master: Move pre-3.44 Cinder post live migration test to test_compute_mgr https://review.opendev.org/683597
15:02:24 openstackgerrit Merged openstack/os-resource-classes master: Build pdf docs https://review.opendev.org/681463
15:13:38 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Use the "memory" mode 'preferred' for a guest NUMA node https://review.opendev.org/684375
15:14:13 kashyap sean-k-mooney: ^ In your "copious spare time"
15:14:34 kashyap sean-k-mooney: Shouldn't we consider migration here: if an instance from a Compute node with 'strict' is being migrated to a host with 'preferred' - possible explosions?
15:15:01 kashyap sean-k-mooney: Err, that main commit summary is nonsense, let me fix that
15:15:06 sean-k-mooney yes this would need to be taken into account
15:15:38 sean-k-mooney but if we hardcore preferred then it not an issue excapt on upgrde
15:15:49 sean-k-mooney it would be fixed by a hard reboot
15:16:54 sean-k-mooney i would not nessisarly require this to be handeled in live migration given that numa live migration was not really correct until train
15:19:18 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Use the `preferred` memory allocation mode for NUMA https://review.opendev.org/684375
15:19:31 aspiers kashyap: "pfalsh" typo in https://libvirt.org/formatdomaincaps.html#elementsOSBIOS
15:19:47 kashyap aspiers: Ah, you saw the libvirt patch I Cced you on?
15:19:50 aspiers yes
15:20:04 kashyap aspiers: Will fix; it's merged already :D
15:20:11 kashyap Thanks for spotting; feel free to reply there
15:20:25 aspiers kashyap: So I saw. Thanks - don't think I'm subscribed to that list
15:20:46 kashyap sean-k-mooney: Ah-ha; good point on "NUMA + live migration not really being a 'thing' until Train"
15:20:47 aspiers kashyap: While you're at it, you could add some helpful hyperlinks
15:21:13 sean-k-mooney kashyap: well it was a thing but it had a load of edgecases
15:21:15 kashyap aspiers: You don't need to be subscribed; just reply they moderators will (usually, quickly) take care
15:21:27 sean-k-mooney so i dont really considre this edgecase to be important
15:21:40 sean-k-mooney at least not relitive to the other ones that were not handeled
15:21:45 kashyap sean-k-mooney: So, an upgrade note is required, too, along with the 'fixes' note I added -- isn't it?
15:21:56 aspiers kashyap: I'd rather not get involved - too much other stuff to deal with :)
15:21:58 kashyap aspiers: Mind pointing out which ones?
15:22:03 kashyap aspiers: Heh, I hear ya
15:22:16 aspiers kashyap: Here are some suggested edits
15:22:18 aspiers "For the loader element, the following can occur:"
15:22:28 aspiers "the following elements can occur:"
15:22:36 kashyap (Oh, I wanted to fix that, too! Realized it too late)
15:22:43 aspiers but then you list "value" alongside "type" etc. which is incorrect
15:22:55 aspiers type/readonly/secure are values of the name attribute of <enum>
15:22:56 sean-k-mooney we could update the numa migration code in train to also update it to prefered
15:22:59 aspiers but you don't even mention <enum>
15:23:03 sean-k-mooney but i would do that as a seperate patch
15:23:44 aspiers and the confusion over the point of <enum> was the whole reason we started looking at this in the first place
15:24:15 aspiers kashyap: ^^^
15:25:00 kashyap aspiers: Okay, my brain is completely exhausted for the moment; will make a note to get back to this and submit a patch
15:25:03 kashyap Thanks!
15:25:05 aspiers kashyap: "For cases like that, os element exposes ..." is ambiguous about whether it's <os> in domCaps or caps
15:25:12 aspiers which again was the crux of the confusion
15:25:28 aspiers These docs need to be crystal clear about when they are referring to elements of domCaps vs. caps
15:25:50 aspiers so that the parallel between the two is understood
15:26:33 kashyap aspiers: I didn't touch those bits; but you're right, they _do_ need "less careless" documentation. I'll get back to this tomm / this week
15:26:45 aspiers kashyap: thanks! one more pointer
15:26:49 kashyap Non-null?
15:26:53 kashyap :D
15:27:06 aspiers kashyap: I'm suggesting to hyperlink text like "the <loader/> element in the domain XML"
15:27:20 aspiers should link to https://libvirt.org/formatdomain.html#elementLoader
15:27:29 aspiers in both directions, ideally
15:27:39 aspiers kashyap: feel free to send me something to review
15:27:43 aspiers when you have a chance

Earlier   Later