Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-07-17
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
00:27:03 openstackgerrit Artom Lifshitz proposed openstack/nova master: Deprecate CONF.workarounds.enable_numa_live_migration https://review.opendev.org/640021
03:23:51 openstackgerrit Alex Xu proposed openstack/nova master: [WIP] Using the claim/unclaim_for_instance for mdevs https://review.opendev.org/671222
03:23:51 openstackgerrit Alex Xu proposed openstack/nova master: [WIP] Populate the existing mediated devices in the libvirt device manager https://review.opendev.org/670787
03:23:52 openstackgerrit Alex Xu proposed openstack/nova master: Add DeviceManager to the libvirt virt driver https://review.opendev.org/671388
05:20:30 openstackgerrit Alex Xu proposed openstack/nova master: Populates the existing mediated devices in the libvirt device manager https://review.opendev.org/670787
05:20:31 openstackgerrit Alex Xu proposed openstack/nova master: Adds functional test for creating the instance with vgpus https://review.opendev.org/671398
05:20:31 openstackgerrit Alex Xu proposed openstack/nova master: Using the claim/unclaim_for_instance for mdevs https://review.opendev.org/671222
05:22:09 alex_xu bauzas: ^ need your review on those patches, I move the mdev into the new claim_for_instance interface
06:30:50 openstackgerrit Alex Xu proposed openstack/nova master: Add DeviceManager to the libvirt virt driver https://review.opendev.org/671388
06:30:51 openstackgerrit Alex Xu proposed openstack/nova master: Using the claim/unclaim_for_instance for mdevs https://review.opendev.org/671222
06:30:51 openstackgerrit Alex Xu proposed openstack/nova master: Populates the existing mediated devices in the libvirt device manager https://review.opendev.org/670787
06:30:52 openstackgerrit Alex Xu proposed openstack/nova master: Adds functional test for creating the instance with vgpus https://review.opendev.org/671398

Earlier   Later