Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-16
17:51:09 mdbooth It goes away when they finish the upgrade
17:51:14 mdbooth lyarwood: Does it?
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: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: Add get_traits() method to ComputeDriver https://review.openstack.org/532287
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:27 openstackgerrit Mark Goddard proposed openstack/nova master: Implement get_traits() for the ironic virt driver https://review.openstack.org/532288
17:59:27 openstackgerrit Mark Goddard proposed openstack/nova master: Call get_traits() in the resource tracker https://review.openstack.org/532290
17:59:40 openstackgerrit Eric Fried proposed openstack/nova master: SchedulerReportClient.set_traits_for_provider https://review.openstack.org/532564
17:59:40 openstackgerrit Eric Fried proposed openstack/nova master: ProviderTree.snapshot => ProviderSnapshot https://review.openstack.org/533244
17:59:41 openstackgerrit Eric Fried proposed openstack/nova master: Raise on API errors getting aggregates/traits https://review.openstack.org/526540
17:59:41 openstackgerrit Eric Fried proposed openstack/nova master: Track associated sharing RPs in report client https://review.openstack.org/526539
17:59:42 openstackgerrit Eric Fried proposed openstack/nova master: Track tree-associated providers in report client https://review.openstack.org/526541
17:59:42 openstackgerrit Eric Fried proposed openstack/nova master: ProviderTree.populate_from_iterable https://review.openstack.org/520756
17:59:43 openstackgerrit Eric Fried proposed openstack/nova master: SchedulerReportClient.get_provider_tree https://review.openstack.org/521098
17:59:43 openstackgerrit Eric Fried proposed openstack/nova master: SchedulerReportClient.set_aggregates_for_provider https://review.openstack.org/533808
17:59:44 openstackgerrit Eric Fried proposed openstack/nova master: WIP: SchedulerReportClient.update_from_provider_tree https://review.openstack.org/533821
17:59:44 openstackgerrit Eric Fried proposed openstack/nova master: ComputeDriver.update_provider_tree() https://review.openstack.org/521187
17:59:45 openstackgerrit Eric Fried proposed openstack/nova master: Fix nits in update_provider_tree series https://review.openstack.org/531260
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: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 jaypipes melwitt: still sounds like a half-baked "feature" to me...
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: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: placement: _get_trees_matching_all() https://review.openstack.org/531512
18:12:56 openstackgerrit Jay Pipes proposed openstack/nova master: add _has_provider_trees() utility function https://review.openstack.org/531474
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:12:57 openstackgerrit Jay Pipes proposed openstack/nova master: add tests for _get_trees_matching_all() with trait https://review.openstack.org/531899
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?
18:28:21 efried edleafe ProviderTree doesn't have a generation. A single provider does.
18:28:43 efried edleafe Back to the thing where individual providers are hidden in the ProviderTree.
18:29:03 edleafe efried: ok, I thought there was something I was missing
18:29:26 efried ProviderTree.snapshot(rp_uuid).generation *works* - it's just wildly inefficient.
18:30:25 edleafe efried: are there other atts besides generation that you have a need to access?
18:31:14 openstackgerrit Lee Yarwood proposed openstack/nova master: rbd: flatten images when creating/unshelving an instance https://review.openstack.org/457886
18:31:43 efried edleafe Yes, the complex ones (aggs, traits, inventory) which we *must* copy out. Primitives, though... maybe parent_uuid? Eventually name?
18:32:16 efried edleafe More will shake out once drivers start implementing update_provider_tree.
18:33:11 edleafe efried: so are you thinking something like: ptree.getattr(rp_uuid, attname) ?
18:34:42 efried edleafe Initially I was just thinking about ptree.generation_for(rp_uuid), qua https://review.openstack.org/532922
18:35:16 edleafe efried: well, that's why I asked if you will need this for more than just generation
18:35:39 efried edleafe Surely. Even so, the idea of N accessors was discussed on Monday and jaypipes expressed a preference for doing it this way.
18:35:49 edleafe efried: it would suck to have ptree.name_for(rp_uuid), ptree.parent_uuid_for(rp_uuid), etc.
18:35:55 efried agreeeeed.
18:36:10 efried edleafe I think what I'm actually coming around to is that we shouldn't do the deep copy of the nested children in .snapshot() - at least not by default.
18:36:46 efried edleafe Then at least we're only throwing away one provider's worth of stuff we copied for no reason.
18:38:11 sean-k-mooney stephenfin: jaypipes i ran all the tempest smoke test + senario test + tox -e py35,py27,functional,pep8,docs locally on https://review.openstack.org/#/c/534307/2 here http://paste.openstack.org/show/645744/ all passed so just waiting on the gate to do the same.

Earlier   Later