| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-17 | |||
| 15:55:47 | openstackgerrit | Dakshina Ilangovan proposed openstack/nova-specs master: Spec: Provider config YAML file https://review.opendev.org/612497 | |
| 15:56:18 | zzzeek | is mriedem on vacation | |
| 15:56:38 | dansmith | zzzeek: yes | |
| 15:56:47 | zzzeek | dansmith: hokay | |
| 16:01:50 | edleafe | b | |
| 16:02:05 | edleafe | *ETOOMANYTERMINALSOPEN | |
| 16:19:32 | efried | IMO it's pretty much ready to go - but I may be too close to it to see the gaps. | |
| 16:19:32 | efried | gibi: dansmith: cdent: I gotta roll, but would you please have a look at the providers.yaml spec soonish? https://review.opendev.org/#/c/612497/ | |
| 16:19:55 | cdent | aye aye, will poke at it tomorrow mornig | |
| 17:02:30 | stephenfin | sean-k-mooney: What do we do if none of 'vcpu_pin_set', '[compute] cpu_shared_set' or '[compute] cpu_dedicated_set' are configured? | |
| 17:03:10 | stephenfin | I'm thinking we need to return both VCPUs and PCPUs for all host cores, like we would do if 'vcpu_pin_set' is configured | |
| 17:03:35 | stephenfin | But if we do that, we'll introduce a possibly breaking change when we stop doing that in U | |
| 17:04:40 | sean-k-mooney | if none are set then ya | |
| 17:04:50 | sean-k-mooney | i would report all host cpus as both | |
| 17:05:46 | sean-k-mooney | ideally we would require that one of cpu_shared_set or cpu_dedicated_set are set going forward | |
| 17:05:59 | sean-k-mooney | and issue a warning if neither are set | |
| 17:07:21 | stephenfin | Cool. Going to push drafts of this in a few minutes. It will fail every gate test there is but it should be good enough to see where I'm going with it | |
| 17:07:34 | sean-k-mooney | e.g in train we report both and issue warning. in U if you dont set one of the cpu_shared_set or cpu_dedicated_set we raise an error and refuse to start | |
| 17:11:36 | openstackgerrit | Merged openstack/nova master: Restore RT.old_resources if ComputeNode.save() fails https://review.opendev.org/668263 | |
| 17:28:36 | openstackgerrit | sean mooney proposed openstack/nova master: Libvirt: add support for vPMU configuration. https://review.opendev.org/671338 | |
| 17:29:14 | sean-k-mooney | i think ^ is the full implemtation of the vPMU spec | |
| 17:29:38 | sean-k-mooney | its pretty short so should be a quick win if people want to review. | |
| 17:29:52 | openstackgerrit | Dakshina Ilangovan proposed openstack/nova-specs master: Spec: Provider config YAML file https://review.opendev.org/612497 | |
| 17:30:52 | sean-k-mooney | its 75% unit tests,docs and release notes and like 40 lines of code that does something userful | |
| 17:32:26 | sean-k-mooney | ... actully its proably goign to fail the notification api tests... | |
| 17:33:05 | sean-k-mooney | i was actully trying to have it ready to mrege in the first patch but oh well | |
| 19:07:03 | artom | dansmith, around? Let's say with save a Nova object in one nova component, for example calling in nova-compute instance.save() after setting instance.migration_context | |
| 19:07:26 | artom | And then later, a different instance object, without migration_context lazy-loaded, also gets save()'ed, in the conductor | |
| 19:07:35 | artom | Will the second save clobber the first's migration_context? | |
| 19:08:18 | dansmith | meaning will the not-context-having instance.save() cause the migration context to go away? | |
| 19:08:52 | artom | Yeah | |
| 19:09:17 | dansmith | it shouldn't.. that would be a bug.. this is why objects track dirty fields.. so we know what to update in the database and what to leave as-is | |
| 19:10:02 | artom | (I tried to understand save()'s code, it's not super scrutable) | |
| 19:10:15 | artom | dansmith, ack, much thanks | |
| 19:11:13 | dansmith | instance is complicated, thus is has a complicated save handler | |
| 19:11:37 | dansmith | the actual save is not innate behavior for objects, it has to be implemented each time, so always an opportunity for a bug | |
| 19:12:15 | artom | There's no default "save each field into its column" implementation? | |
| 19:12:36 | artom | "each field" being overly simplistic | |
| 19:12:37 | dansmith | no | |
| 19:13:07 | dansmith | the number of objects that are just a simple "this field goes unchanged in this column" was never 100%, and has shrunk ever since | |
| 19:13:38 | dansmith | at a low-level, any object that is like that would just have a save handler of db_obj.update(self.obj_get_changes()), but even the ones that are 1:1 mappings aren't that simple, | |
| 19:13:55 | dansmith | because they check a few things, look up the db object maybe not in the same way first, etc | |
| 19:24:09 | artom | Dammit journalctl | |
| 19:24:34 | artom | I dunno what kind of "optimization" it does, but if I journalctl -e a thing, and then reverse search for a word, I want to see it | |
| 19:24:59 | artom | Doesn't matter if you haven't actually loaded it in memory or whatever you're doing | |
| 19:25:19 | artom | Because without the -e doing a forward search, it shows up just fine | |
| 19:26:50 | artom | Or even scrolling to the end manually in less, then doing a reverse search | |
| 19:42:01 | artom | dansmith, and actually, I'm an idiot, because the first thing apply_migration_context() does is check self.migration_context, so it'll lazy-load it regardless | |
| 19:42:17 | artom | (That's the bug I'm chasing, migration context not being correctly applied) | |
| 19:42:47 | artom | Ah no, it could still get clobbered after | |
| 19:42:53 | artom | Bleah, moar coffee | |
| 19:44:18 | dansmith | artom: those two things may both be true, but are unrelated I believe | |
| 19:44:31 | artom | dansmith, yeah, just came to that realization | |
| 19:44:49 | dansmith | artom: I meant you being an idiot and "the first thing apply_migration_context" does :) | |
| 19:45:12 | artom | Ah, in that case, I came to the first half of that realization a long time ago :P | |
| 19:46:03 | dansmith | hah | |
| 19:47:55 | artom | Waaay ahead of you there buddy :) | |
| 19:56:09 | artom | The whole migration context is a red herring | |
| 19:56:13 | artom | It's applied correctly | |
| 19:56:22 | artom | What's being clobbered is the numa_topology | |
| 19:56:49 | artom | Because while the apply_migration_context() saves the new one to the instance from the mig_cxtx, there's a save() later when the source cleans up | |
| 19:57:01 | artom | And that instance object still has the original numa_topology | |
| 20:00:28 | openstackgerrit | Merged openstack/nova master: vif: Remove dead minimum libvirt checks https://review.opendev.org/666814 | |
| 20:08:24 | artom | BOOM | |
| 20:13:02 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: [WIP-until-series-is-ready] Introduce live_migration_claim() https://review.opendev.org/635669 | |
| 20:13:03 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: LM: add support for sending NUMAMigrateData to the source https://review.opendev.org/634828 | |
| 20:13:03 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: New objects for NUMA live migration https://review.opendev.org/634827 | |
| 20:13:04 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: RPC changes to prepare for NUMA live migration https://review.opendev.org/634605 | |
| 20:13:04 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: LM: add support for updating NUMA-related XML on the source https://review.opendev.org/635229 | |
| 20:13:05 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Deprecate CONF.workarounds.enable_numa_live_migration https://review.opendev.org/640021 | |
| 20:13:05 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: NUMA live migration support https://review.opendev.org/634606 | |
| 20:13:29 | artom | And with that perfect timing, it's daycare time | |
| 20:16:24 | efried_rollin | stephenfin, sean-k-mooney: what do you mean, report them as both VCPU and PCPU? Won't that lead to double the real inventory? | |
| 20:17:21 | efried_rollin | artom: don't forget pysnooper | |
| 21:20:45 | efried | dansmith: deployers can implement their own filters, right? | |
| 21:20:56 | dansmith | efried: scheduler filters? | |
| 21:20:59 | efried | yeah | |
| 21:21:45 | efried | dansmith: that live on the compute and get the option to say "this host is no good for this instance" | |
| 21:22:12 | dansmith | efried: live on the compute? | |
| 21:22:22 | efried | do they not live on the compute? They live on the scheduler? | |
| 21:22:30 | dansmith | but yeah, scheduler filters are the only real plug point we offer | |
| 21:22:41 | dansmith | efried: scheduler filters? yeah they live on the ... scheduler :) | |
| 21:23:07 | efried | dansmith: So the NUMATopologyFilter lives on the scheduler despite needing to know very specific things about the NUMA topology of the host it's filtering for? | |
| 21:23:55 | efried | (recognizing that one is an us-provided filter, that does things beyond just binarily saying yea or nay to a host) | |
| 21:24:45 | dansmith | efried: yeah, that's kinda the whole point | |
| 21:25:09 | efried | okay; I mean I'm just curious how the NUMATopologyFilter gets to know those things about the hosts | |
| 21:25:11 | dansmith | I'm not even sure how you're thinking things would/could be working with them on the compute | |
| 21:25:29 | dansmith | but the compute and virt driver expose a generalized model so the scheduler can operate on an abstraction, because not all clouds have all the same hypervisors, versions of hypervisors, etc | |
| 21:25:37 | efried | I guess the compute service comes up and detects the topology and reports it back to the scheduler or puts it in the database or something. | |
| 21:25:42 | dansmith | efried: they expose a generalized model | |
| 21:34:04 | efried | dansmith: thanks. I posted answers to your comments on the providers.yaml spec. LMK if you want to discuss (since Dakshina doesn't really seem to do IRC ): | |
| 21:34:25 | dansmith | ack, it'll be tomorrow | |
| 21:34:42 | efried | thanks | |
| 23:30:04 | openstackgerrit | Merged openstack/python-novaclient master: Add Python 3 Train unit tests https://review.opendev.org/669439 | |
| #openstack-nova - 2019-07-18 | |||
| 00:26:59 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: [WIP-until-series-is-ready] Introduce live_migration_claim() https://review.opendev.org/635669 | |
| 00:27:00 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: LM: add support for sending NUMAMigrateData to the source https://review.opendev.org/634828 | |
| 00:27:00 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: New objects for NUMA live migration https://review.opendev.org/634827 | |
| 00:27:01 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: RPC changes to prepare for NUMA live migration https://review.opendev.org/634605 | |
| 00:27:01 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: LM: add support for updating NUMA-related XML on the source https://review.opendev.org/635229 | |
| 00:27:02 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: NUMA live migration support https://review.opendev.org/634606 | |