Posted	Nick	Remark
#openstack-nova - 2018-01-16
17:47:11	lyarwood	ah right, in that old to native use case, you're correct
17:47:12	mdbooth	I think we're uncovering a design defect in live migration here, tbh
17:47:22	mdbooth	But it is what it is
17:47:50	openstackgerrit	Eric Fried proposed openstack/nova master: ProviderTree.snapshot => ProviderSnapshot https://review.openstack.org/533244
17:47:50	openstackgerrit	Eric Fried proposed openstack/nova master: SchedulerReportClient.set_traits_for_provider https://review.openstack.org/532564
17:47:51	openstackgerrit	Eric Fried proposed openstack/nova master: Track associated sharing RPs in report client https://review.openstack.org/526539
17:47:51	openstackgerrit	Eric Fried proposed openstack/nova master: Raise on API errors getting aggregates/traits https://review.openstack.org/526540
17:47:52	openstackgerrit	Eric Fried proposed openstack/nova master: ProviderTree.populate_from_iterable https://review.openstack.org/520756
17:47:52	openstackgerrit	Eric Fried proposed openstack/nova master: Track tree-associated providers in report client https://review.openstack.org/526541
17:47:53	openstackgerrit	Eric Fried proposed openstack/nova master: SchedulerReportClient.set_aggregates_for_provider https://review.openstack.org/533808
17:47:53	openstackgerrit	Eric Fried proposed openstack/nova master: SchedulerReportClient.get_provider_tree https://review.openstack.org/521098
17:47:54	openstackgerrit	Eric Fried proposed openstack/nova master: ComputeDriver.update_provider_tree() https://review.openstack.org/521187
17:47:54	openstackgerrit	Eric Fried proposed openstack/nova master: WIP: SchedulerReportClient.update_from_provider_tree https://review.openstack.org/533821
17:47:55	openstackgerrit	Eric Fried proposed openstack/nova master: WIP: Use update_provider_tree from resource tracker https://review.openstack.org/520246
17:47:55	openstackgerrit	Eric Fried proposed openstack/nova master: Fix nits in update_provider_tree series https://review.openstack.org/531260
17:47:59	efried	mgoddard This whole thing has been rearranged and rebased ^
17:48:20	efried	mgoddard I noticed you put some stuff on top (or in the middle, or something) - it'll need to be rebased accordingly.
17:48:24	mdbooth	efried: Zuul can take another one for the team ;)
17:48:49	mdbooth	lyarwood: So I'm not 100% sure what the state would be on the destination
17:48:57	efried	mdbooth The way zuul has been treating me lately, I don't have too much sympathy.
17:49:03	mdbooth	efried: Hehe
17:49:08	efried	Course, zuul is in the position of power, there.
17:49:38	efried	jaypipes See above: snapshot comes first now, followed by set_traits_for_provider so mgoddard can use it for the ironic traits bp.
17:49:59	mdbooth	lyarwood: Given that this would be a hopefully ephemeral situation, I wonder if we can detect this in pre_live_migration and fail early.
17:50:47	mdbooth	lyarwood: i.e. the fix is to not allow live migration host->native encryption
17:51:00	lyarwood	mdbooth: well, this breaks native to native as well right?
17:51:09	mdbooth	It goes away when they finish the upgrade
17:51:14	lyarwood	mdbooth: if we can't lookup the UUID of the new secret on the dest and udpate the XML we can't migrate
17:51:14	mdbooth	lyarwood: Does it?
17:51:38	lyarwood	mdbooth: we'd just end up pointing to the src secret UUID that doesn't exist on the dest
17:51:45	mdbooth	lyarwood: I thought we were using the volume id as the secret uuid, no?
17:52:16	lyarwood	mdbooth: no, the lookup code uses the volume_id, the actual secret has a seperate UUID you need to provide in the XML
17:52:24	efried	oh gdi. Stupid pep8 mistakes. And on the bottom patch, of course.
17:53:00	mdbooth	efried: LOL. FWIW: 'git rebase -i master -x "tox -e pep8 -- -HEAD"' is your friend
17:53:23	efried	ooo
17:53:29	mdbooth	Will run pep8 against each of your patches individually
17:53:32	jaypipes	efried: acl
17:53:34	efried	That's slightly easier than the way I was gonna do it.
17:53:36	jaypipes	ack
17:55:40	mdbooth	lyarwood: Well, without checking the libvirt api specifically, sounds like that's broken :(
17:55:53	mdbooth	This must have come up in a different context.
17:56:42	lyarwood	mdbooth: I wonder if we can create a secret with the same UUID on the dest?
17:57:30	esberglu	stephenfin: Responded to your OVS questions
17:57:36	mdbooth	lyarwood: This works currently, right?
17:57:56	mdbooth	i.e. We can't just not support it, because that would be a regression.
17:58:12	lyarwood	mdbooth: LM with encrypted volumes? Yeah AFAIK it does.
17:58:25	mdbooth	lyarwood: You'd need a config variable to switch it off ;) You should add one of those.
17:58:35	lyarwood	\o/
17:58:55	lyarwood	mdbooth: brb
17:59:02	mdbooth	I have to run, but I don't believe this is beyond the wit of man.
17:59:16	mdbooth	lyarwood: Catch up tomorrow afternoon?
17:59:26	openstackgerrit	Mark Goddard proposed openstack/nova master: WIP: Send traits to ironic on server boot https://review.openstack.org/508116
17:59:26	openstackgerrit	Mark Goddard proposed openstack/nova master: Add get_traits() method to ComputeDriver https://review.openstack.org/532287
17:59:27	openstackgerrit	Mark Goddard proposed openstack/nova master: Call get_traits() in the resource tracker https://review.openstack.org/532290
17:59:27	openstackgerrit	Mark Goddard proposed openstack/nova master: Implement get_traits() for the ironic virt driver https://review.openstack.org/532288
17:59:40	openstackgerrit	Eric Fried proposed openstack/nova master: ProviderTree.snapshot => ProviderSnapshot https://review.openstack.org/533244
17:59:40	openstackgerrit	Eric Fried proposed openstack/nova master: SchedulerReportClient.set_traits_for_provider https://review.openstack.org/532564
17:59:41	openstackgerrit	Eric Fried proposed openstack/nova master: Track associated sharing RPs in report client https://review.openstack.org/526539
17:59:41	openstackgerrit	Eric Fried proposed openstack/nova master: Raise on API errors getting aggregates/traits https://review.openstack.org/526540
17:59:42	openstackgerrit	Eric Fried proposed openstack/nova master: ProviderTree.populate_from_iterable https://review.openstack.org/520756
17:59:42	openstackgerrit	Eric Fried proposed openstack/nova master: Track tree-associated providers in report client https://review.openstack.org/526541
17:59:43	openstackgerrit	Eric Fried proposed openstack/nova master: SchedulerReportClient.set_aggregates_for_provider https://review.openstack.org/533808
17:59:43	openstackgerrit	Eric Fried proposed openstack/nova master: SchedulerReportClient.get_provider_tree https://review.openstack.org/521098
17:59:44	openstackgerrit	Eric Fried proposed openstack/nova master: ComputeDriver.update_provider_tree() https://review.openstack.org/521187
17:59:44	openstackgerrit	Eric Fried proposed openstack/nova master: WIP: SchedulerReportClient.update_from_provider_tree https://review.openstack.org/533821
17:59:45	openstackgerrit	Eric Fried proposed openstack/nova master: WIP: Use update_provider_tree from resource tracker https://review.openstack.org/520246
17:59:45	openstackgerrit	Eric Fried proposed openstack/nova master: Fix nits in update_provider_tree series https://review.openstack.org/531260
17:59:48	efried	There, ffs. mgoddard Sorry dude
18:00:39	lyarwood	mdbooth: sure, thanks again
18:00:47	melwitt	jaypipes: scheduler question for you ... when the filter scheduler does the compute node prune based on placement before going through the scheduler filters, does it take into consideration overcommit values set by aggregate?
18:01:28	jaypipes	melwitt: no
18:01:53	jaypipes	melwitt: placement has no concept of "aggregate overcommit"
18:03:22	melwitt	jaypipes: k, that's what I was thinking
18:05:02	melwitt	jaypipes: we're seeing issues where all of the overcommit was set via aggregates, so placement is filtering out very many nodes that can actually serve requests given overcommit
18:05:31	melwitt	as a workaround I was thinking, have to set overcommit per compute node in nova.conf to get around this
18:06:51	jaypipes	melwitt: I'll be honest, I didn't know about setting overcommit via aggregate.
18:07:04	jaypipes	melwitt: sounds like a half (quarter?)-baked feature
18:07:27	melwitt	heh. well, it's the AggregateCoreFilter and friends
18:07:48	jaypipes	melwitt: and as we've discussed before, aggregates and Ironic don't mix. at all...
18:08:06	jaypipes	melwitt: or is this not an ironic thing?
18:08:13	melwitt	this is not an ironic thing
18:08:24	jaypipes	kk
18:08:47	melwitt	since they're doing overcommit via aggregate, placement is returning only like 6 nodes when 20+ can fulfill given overcommit
18:08:47	jaypipes	melwitt: still sounds like a half-baked "feature" to me...
18:09:20	melwitt	meaning, you expect setting overcommit per compute node should be the fully baked way?
18:09:44	melwitt	just trying to understand how they should proceed going forward
18:09:46	jaypipes	melwitt: yes. it's the *only* way.
18:11:47	melwitt	k. I think the concern there is it hurts usability of aggregates. setting them per aggregate (a few times) vs setting them per compute node (a lot of times)
18:11:48	cdent	overcommit by aggregate. interesting. yet another thing I've never heard of before. I can see the appeal
18:12:19	melwitt	since aggregate means "bucket of like compute nodes" I can see how one would want to set overcommit same per bucket
18:12:33	melwitt	*since aggregate usually means
18:12:56	openstackgerrit	Jay Pipes proposed openstack/nova master: add _has_provider_trees() utility function https://review.openstack.org/531474
18:12:56	openstackgerrit	Jay Pipes proposed openstack/nova master: placement: _get_trees_matching_all() https://review.openstack.org/531512
18:12:57	openstackgerrit	Jay Pipes proposed openstack/nova master: add tests for _get_trees_matching_all() with trait https://review.openstack.org/531899
18:12:57	openstackgerrit	Jay Pipes proposed openstack/nova master: add test for scenario with sum of child resources https://review.openstack.org/534339
18:13:31	jaypipes	melwitt: an aggregate in placement doesn't have any metadata associated with it at all. it's a pure grouping mechanism.
18:14:30	efried	stephenfin Not sure which two comments were the ones holding you back. Let us know if we can clarify anything further. Thanks for the review!
18:14:31	melwitt	jaypipes: yeah, I understand. just pointing out the high level effect on the usability in this case
18:14:40	jaypipes	melwitt: the problem with the aggregate overcommit thing in Nova is what happens when the compute node's allocation ratio is != the aggregate's allocation ratio? also, what happens when a compute node is in multiple aggregates? which allocation ratio should be used? all these things are not issues in placement because we don't store metadata for aggregates.
18:15:11	melwitt	jaypipes: good points

Earlier   Later