Earlier  
Posted Nick Remark
#openstack-nova - 2020-11-19
15:47:02 artom And yet...
15:47:46 sean-k-mooney what are yo trying to check?
15:47:54 sean-k-mooney unpinned to pinned works fine
15:47:55 stephenfin artom: You need to disable the workaround option
15:47:59 sean-k-mooney or at least it used too
15:48:14 stephenfin artom: '[workarounds] disable_fallback_pcpu_query'
15:48:29 stephenfin and then it'll fail
15:48:34 sean-k-mooney ah yes
15:48:38 sean-k-mooney so it uses pcpus
15:49:06 sean-k-mooney artom: the current behavior with the fallback enabeld is expected
15:49:18 artom stephenfin, can I be lazy and ask you to remind me what the fallback query actually queries for?
15:49:23 artom Ah, just VCPUs?
15:49:27 gibi dansmith: re: install doc. So those docs could be the place where we define the minimal config. As a first look at leat the compute doc did not ask for a DB config :)
15:49:36 sean-k-mooney artom: yep vcpus
15:49:38 dansmith gibi: yeah
15:49:47 artom Wouldn't it fail on the host though?
15:49:54 sean-k-mooney artom: no
15:49:59 dansmith gibi: I dunno about you, but I'm not sure that having three separate docs for three separate distro flavors is really necessary,
15:50:13 sean-k-mooney artom: it should
15:50:17 gibi dansmith: I did not diff them but they look similar
15:50:18 stephenfin artom: when that's configured, the scheduler will make a second, fallback request for VCPU inventory, yeah
15:50:22 dansmith gibi: especially since the ubuntu one (at least) already has some stale stuff I can see (not using systemctl)
15:50:26 sean-k-mooney but im not sure stephenfin pach has been merged
15:50:35 dansmith gibi: yeah there are a couple tweaks made to one that aren't in the other, unrelated to distro stuff
15:50:45 dansmith gibi: having them separate makes that a real likely possibility
15:50:48 stephenfin as for failing on the host, I'm trying to recall...
15:50:49 sean-k-mooney artom: if they dont have cpu_dedicate_set configure then it should boot on the host
15:51:20 gibi dansmith: so we could merge them and just add notes about the destro specific things
15:51:20 sean-k-mooney stephenfin: it should only fail on the host if cpu_dedicated_set is defiend
15:51:27 stephenfin sean-k-mooney: yeah, correct
15:51:29 artom stephenfin, I'd expect virt.hardware to not pin CPUs if neither vcpu_pin_set or cpu_dedicated_set is configured...
15:51:41 stephenfin artom: we can't do that - we'd break upgrades
15:51:43 dansmith gibi: or we could merge them and try to stay out of the distro business
15:51:44 sean-k-mooney artom: your expectiojn is wrong
15:52:02 sean-k-mooney yep what stephenfin said
15:52:10 dansmith gibi: like say "install packages now, probably $ubuntuish or $redhatish"
15:52:30 stephenfin say you have a user that was using pinned instances before Train. Their host would be reporting VCPU and those pinned instances would be booting whether or not vcpu_pin_set was defined
15:53:02 artom stephenfin, hol'up, maybe that's where I got it wrong
15:53:13 stephenfin after the upgrade, those hosts will still report VCPU (because 'cpu_dedicated_set' isn't defined), which is why we need the fallback query
15:53:19 artom I assumed if you don't have vcpu_pin_set you can't boot pinned instances...
15:53:26 sean-k-mooney you can
15:53:28 artom Or will we just chose any old CPUs?
15:53:38 sean-k-mooney vcpu_pin_set is nothign to do with pinning
15:53:39 stephenfin nope. That _should_ have been the case, but it wasn't
15:53:45 gibi dansmith: yeah, that make sense
15:53:49 sean-k-mooney its the set of host you can boot a vm on
15:53:54 sean-k-mooney *cpus
15:53:58 sean-k-mooney if unset its all cpus
15:53:59 stephenfin artom: within the constraints of NUMA, yes
15:54:16 stephenfin pinning means NUMA, which means a guest NUMA node is constrained to a host NUMA node
15:54:31 stephenfin yeah, what sean-k-mooney said
15:54:49 artom Aha, thanks for bringing me up to speed
15:55:04 stephenfin I said we should have required it because pinning to e.g. host core 0 isn't a great idea, but there's no relationship between the option and pinning, as sean-k-mooney says
15:55:19 artom Well, there is if it's set :P
15:55:47 artom Are the semantics the same with cpu_dedicated_set? IOW, if that's None, can we still pin to anything?
15:55:47 stephenfin sure, but unpinned instances booted to the same host will be bound to that set too
15:56:08 artom Ah, it was just the set of CPUs usable by instances
15:56:09 gibi dansmith: having just a controller config enough? or we need a separate scheduler config, conductor config, etc?
15:56:09 stephenfin artom: at the moment, yes, because of upgrade reasons
15:56:10 artom Of any kind
15:56:22 artom I feel like I should know this stuff
15:56:24 stephenfin yes, exactly. Not specific to pinning policy
15:56:28 gibi dansmith: like the scheduler only need the API database I guess
15:56:35 dansmith gibi: well, with cells there needs to be some differences, that's why we're here
15:56:59 stephenfin artom: once we drop support for vcpu_pin_set, you'll have to define 'cpu_dedicated_set'
15:57:05 sean-k-mooney artom: vcpu_pin_set applied to unpinned instance too
15:57:14 sean-k-mooney we set it in the xml
15:57:36 sean-k-mooney artom: which si still a gap in live migration by the way
15:57:44 sean-k-mooney we dont update it for non numa guests
15:58:10 stephenfin I have a draft patch, but I can't submit it because doing so will require removal of the reshape. I'm hoping bauzas gets that offline reshape spec sorted this cycle
15:58:32 bauzas my spec is still open
15:58:59 sean-k-mooney stephenfin: well you mean once we drop the fallback query
15:59:08 gibi nova meeting starts in 1 minute
15:59:13 stephenfin sean-k-mooney: right
15:59:32 sean-k-mooney once that is gon you can only boot pinned vms with pcpus
15:59:32 stephenfin which we'll do at the same time as we drop vcpu_pin_set
15:59:38 stephenfin correct
15:59:40 sean-k-mooney yep
15:59:51 sean-k-mooney but even removing vcpu_pin_set would not be enough
16:00:21 sean-k-mooney since without cpu_dedicated_set but with the fallback enabeld you can boot pinned gusts with vcpus
16:00:34 sean-k-mooney so its really the fallback that is imporant
16:01:23 artom sean-k-mooney, oh yeah, I remember the live migration for cpu_shared_set
16:01:28 artom Should get to it, at some point :P
16:04:52 sean-k-mooney artom: is this reated to a bug or something by the way
16:04:59 sean-k-mooney or just better testing
16:05:00 artom sean-k-mooney, the whitebox CI failures
16:05:08 artom I haven't managed to reproduce the delete failure
16:05:10 sean-k-mooney oh well this is not a bug
16:05:16 artom (In functional tests, at any rate)
16:05:34 sean-k-mooney it might be a missconfiguration or a bug in the white box tests
16:05:39 artom But it's happening because it's deleting the pinned instance when cpu_dedicated_set is None
16:05:45 artom So it complains about unpinning CPUs
16:05:48 artom Well...
16:05:56 sean-k-mooney anytime we define cpu_dedicated_set you should also disable the fallback
16:06:06 sean-k-mooney we likely are not doing the latter
16:06:09 artom We don't define it
16:06:18 sean-k-mooney its enabled by default
16:06:32 artom I mean cpu_dedicated_set
16:06:42 artom What I'm seeing is the test_resize_unpinned_server_to_pinned tearDown is failing
16:06:51 artom Because it can't delete the pinned instance

Earlier   Later