| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-16 | |||
| 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 | |
| 18:15:24 | melwitt | especially the multiple aggregates | |
| 18:16:38 | jaypipes | melwitt: and I'm not trying to be argumentative. just pointing out that there are definitely some things we won't be porting over to placement land... | |
| 18:17:15 | melwitt | jaypipes: understood. I'm not trying to be argumentative either. just looking to understand and be able to explain it to ppl :) | |
| 18:17:21 | melwitt | so thanks | |
| 18:18:55 | jaypipes | melwitt: when discussing a similar thing with operators (having to set traits on compute node resource provider records individually instead of relying on agg metadata) I had suggested a simple CLI tool that would essentially apply a particular trait to all providers associated with an aggregate. they seemed responsive to that idea. | |
| 18:26:14 | efried | jaypipes edleafe cdent gibi For all the hubbub, we may still want to implement an accessor for provider generation. Given the way I'm using it e.g. in https://review.openstack.org/#/c/532564/9/nova/scheduler/client/report.py@1046 | |
| 18:26:19 | melwitt | jaypipes: k, I'll mention that to them. we'll be looking at how to change over from the Aggregate<resource> filters and configure the deployment to set it per compute node | |
| 18:27:09 | melwitt | s/it/overcommit/ | |
| 18:27:56 | edleafe | efried: what's the reason you can't just use generation = self._provider_tree.generation? | |