| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-19 | |||
| 15:27:24 | lpetrut | well, since virtually all Windows Openstack instances use it, I'd say breaking it wouldn't be desired, even though it's just one project | |
| 15:27:25 | sean-k-mooney | apparently it was for hyperv https://blueprints.launchpad.net/nova/+spec/hyper-v-metadata-password-post | |
| 15:27:36 | sean-k-mooney | but it was not appoved | |
| 15:28:09 | sean-k-mooney | thre is no https://blueprints.launchpad.net/nova/+spec/get-password blueprit | |
| 15:28:18 | sean-k-mooney | oh there is | |
| 15:28:22 | sean-k-mooney | it did not come up | |
| 15:28:26 | lpetrut | https://blueprints.launchpad.net/nova/+spec/hyper-v-metadata-password-post seems like an extension of this feature | |
| 15:29:20 | sean-k-mooney | this was first added as an api extention https://review.opendev.org/#/c/17273/ | |
| 15:29:41 | sean-k-mooney | before we removed those | |
| 15:30:36 | sean-k-mooney | so this was nota catully part of the metadata api | |
| 15:30:52 | sean-k-mooney | it was a vendor extntion https://review.opendev.org/#/c/17273/15/nova/api/openstack/compute/contrib/server_password.py | |
| 15:30:55 | lpetrut | nice. thanks for checking. this was an interesting lesson of Nova history :) | |
| 15:31:25 | sean-k-mooney | so ya i think we moved it into the metrada service wehn we got rid fo extensions | |
| 15:33:31 | lpetrut | sorry for mentioning the server actions, that's completely unrelated. it took a while since I last had contact with this code so I was a bit confused. | |
| 15:36:52 | sean-k-mooney | so this changed in liberty | |
| 15:37:05 | sean-k-mooney | that is when we remvod the contib folder | |
| 15:38:04 | sean-k-mooney | ah it move to legacy_v2 contrib | |
| 15:41:03 | sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/api-no-more-extensions.html | |
| 15:42:08 | sean-k-mooney | so this was deprecated in libvirty and removed in newton | |
| 15:43:55 | lpetrut | yep, API extensions were deprecated but then got included in the nova api | |
| 15:44:24 | sean-k-mooney | they were not just all accpeted | |
| 15:44:33 | sean-k-mooney | they needed to be upstreamed | |
| 15:44:52 | lpetrut | makes sense. well, this specific one is part of the nova tree. seems upstream to me :) | |
| 15:46:35 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: WIP: Reproducer for unpinned to pinned resize bug https://review.opendev.org/763399 | |
| 15:46:44 | sean-k-mooney | it got moved by https://github.com/openstack/nova/commit/003c868da73d84d33fba81ee9b033b8ae321e7ab | |
| 15:46:55 | artom | stephenfin, sean-k-mooney, ^^ sanity check that for me pretty please? I feel like I've missed something obvious | |
| 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 | sean-k-mooney | stephenfin: it should only fail on the host if cpu_dedicated_set is defiend | |
| 15:51:20 | gibi | dansmith: so we could merge them and just add notes about the destro specific things | |
| 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 | stephenfin | sure, but unpinned instances booted to the same host will be bound to that set too | |
| 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:56:08 | artom | Ah, it was just the set of CPUs usable by instances | |
| 15:56:09 | stephenfin | artom: at the moment, yes, because of upgrade reasons | |
| 15:56:09 | gibi | dansmith: having just a controller config enough? or we need a separate scheduler config, conductor config, etc? | |
| 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 | |