Posted	Nick	Remark
#openstack-nova - 2019-07-17
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: New objects for NUMA live migration https://review.opendev.org/634827
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: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:04	openstackgerrit	Artom Lifshitz proposed openstack/nova master: RPC changes to prepare for NUMA live migration https://review.opendev.org/634605
20:13:05	openstackgerrit	Artom Lifshitz proposed openstack/nova master: NUMA live migration support https://review.opendev.org/634606
20:13:05	openstackgerrit	Artom Lifshitz proposed openstack/nova master: Deprecate CONF.workarounds.enable_numa_live_migration https://review.opendev.org/640021
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: New objects for NUMA live migration https://review.opendev.org/634827
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: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:01	openstackgerrit	Artom Lifshitz proposed openstack/nova master: RPC changes to prepare for NUMA live migration https://review.opendev.org/634605
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] Populate the existing mediated devices in the libvirt device manager https://review.opendev.org/670787
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: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: Using the claim/unclaim_for_instance for mdevs https://review.opendev.org/671222
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: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: Populates the existing mediated devices in the libvirt device manager https://review.opendev.org/670787
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:52	openstackgerrit	Alex Xu proposed openstack/nova master: Adds functional test for creating the instance with vgpus https://review.opendev.org/671398
06:46:55	openstackgerrit	Yongli He proposed openstack/python-novaclient master: Microversion 2.75 - show server topology https://review.opendev.org/670790
07:43:36	openstackgerrit	Dakshina Ilangovan proposed openstack/nova-specs master: Spec: Provider config YAML file https://review.opendev.org/612497
08:22:07	stephenfin	efried: Correct. We're doing that already and we've decided it's not an issue since operators should already have separate hosts for pinned and non-pinned instances
08:23:33	stephenfin	efried: and if they don't, they get pretty much what they had before, even if placement inventory will be kind of a lie
08:27:12	cdent	lying is bad, mmmkay?
08:44:49	openstackgerrit	QingFeng Hao proposed openstack/nova master: Add get_host_memory_stats in zvm driver https://review.opendev.org/671430
08:48:46	gibi	sean-k-mooney: left comments in https://review.opendev.org/#/c/671338 overall direction looks good to me
08:53:12	sean-k-mooney	gibi: thanks, ya the unit test failures are valid i ran them locally with a regex of things i tought might break but i obviously missed some
09:26:35	openstackgerrit	Stephen Finucane proposed openstack/nova master: tox: Keeping going with docs https://review.opendev.org/670332
09:26:52	kashyap	Heya, a random question: what else tooling do people use besides `git-review` to make life pleasant with Gerrit?
09:27:25	kashyap	(I'm asking because, I'm providing a data point for those who are mailing lists, and are considering web-based workflows, GitLab/GitHub; not Gerrit at this point)
09:27:45	kashyap	I think `gertty` would be another for those who like the offline caching and terminal-based reviews
09:29:44	sean-k-mooney	its mainly git review for me. with web for review. i strongly dislike mailing list based workflows to the point that unless that project also has patchwork i almost entirly avoid them
09:29:59	sean-k-mooney	at least when it comes to code reviews
09:30:06	sean-k-mooney	gertty if fine for reviewing
09:30:35	sean-k-mooney	but its offline asspect comes at the cost that it needs to build up an sql database of the open changes
09:30:45	sean-k-mooney	that can be slow with large repos like nova
09:31:15	gibi	efried: I added comments to https://review.opendev.org/#/c/612497
09:31:39	kashyap	I maintain Gertty in Fedora, FWIW, because I enjoy the offline ability. And the DB build-up is a negligible cost
09:31:50	kashyap	sean-k-mooney: It's not SQL; but Berkely
09:32:07	sean-k-mooney	kashyap: no is sqlight3
09:32:11	kashyap	Ah, right

Earlier   Later