Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-17
17:03:49 dansmith edleafe: it should do whatever would happen if we had no retries left in the current path
17:03:50 dansmith yeah
17:03:51 dansmith that
17:03:58 edleafe mriedem: that was my assumption, but I wanted to be sure there wasn't some other action
17:04:07 openstackgerrit Jan Zerebecki proposed openstack/nova master: Fix wording of debug message for future releases https://review.openstack.org/508261
17:04:31 edleafe ah, so that should be the same as what happens in compute when there are no retries left.
17:04:37 dansmith right
17:08:59 openstackgerrit Elod Illes proposed openstack/nova master: WIP: Transform scheduler.select_destinations notification https://review.openstack.org/508506
17:12:35 dansmith edleafe: so, looking at your third patch,
17:12:43 dansmith edleafe: we have limits in the reqspec,
17:13:03 dansmith oh,
17:13:22 dansmith the selection limits are really just for the return value from the rpc call to continue to include them is that right?
17:13:35 dansmith I was thinking we had to have them for communicating to the compute, but that is in reqspec
17:13:37 dansmith is that right?
17:13:57 edleafe dansmith: the caching scheduler needs them
17:14:16 dansmith the caching scheduler _sets_ them
17:14:22 dansmith the compute _needs_ them
17:14:44 edleafe ok, I thought it was needed in the filters
17:15:02 dansmith my point is, we really just need them in Selection so that the return from select_destinations(), which is now a bunch of Selections, can include the limits back to conductor,
17:15:06 edleafe but yeah, the compute will need them too
17:15:11 dansmith which will populate the reqspec
17:15:22 dansmith the filters don't need them, the filters are what put things into limits
17:15:42 edleafe ok, I guess I misunderstood mriedem's concerns
17:15:49 dansmith compute can get them from the reqspec
17:18:44 mriedem the limits are stored in the reqspec?
17:19:01 mriedem tbc, we pass a reqspec down to build_and_run_instance in compute and it's *totally* ignored
17:19:05 mriedem we pass the limits dict separately
17:19:57 mriedem ok i see the SchedulerLimits field in the request spec
17:20:02 mriedem i just don't think compute is using that today
17:20:14 dansmith mriedem: right, so this will be passing limits N more times than we currently pass it
17:20:39 dansmith I'm thinking maybe we just have select_destinations return (reqspec, alternates) with reqspec updated with limits,
17:20:53 dansmith and then we can avoid putting them into the selection
17:21:10 dansmith aside from numa, they'll be the same for num_instances, right?
17:21:14 mriedem need to see what actually populates RequestSpec.limits today
17:21:26 dansmith I think it's populate_filter_properties
17:23:48 dansmith https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L367
17:24:01 mriedem yeah looking at what calls that
17:24:12 dansmith conductor
17:24:39 dansmith https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L1110-L1110
17:25:03 mriedem god what a weird mess
17:25:11 dansmith yeah
17:25:32 dansmith it's also still in the half-uncleaned-up reqspec object
17:25:42 dansmith the only problem is,
17:25:49 dansmith I think numa limits will be per-host,
17:25:58 dansmith although,hmm
17:26:08 dansmith maybe the regular limits won't because of the allocation ratios or something?
17:26:49 dansmith yeah, toast
17:26:50 mriedem we also aren't doing this trick for evacuate
17:26:51 dansmith gdi
17:27:30 mriedem not really sure why we have RequestSpec.limits at all since it's not used anywhere, i guess because RequestSpec was supposed to replace filter_properties
17:27:48 dansmith the thing that goes into limits for things like ramfilter varies per host
17:27:49 dansmith mriedem: yeah, all that is unfinished
17:28:04 dansmith mriedem: so we pass it in reqspec, and as an arg, and now in N alternates
17:28:21 dansmith oh and we pass filter_properties too
17:28:36 mriedem to build_and_run_instance
17:28:36 dansmith so reqspec, filter_properties, limits, and N*selection
17:28:37 mriedem yeah heh
17:28:46 dansmith I wonder if that's enough redundancy
17:28:58 mriedem RAID-4?
17:29:03 mriedem for limits
17:29:07 dansmith this is like raid 50
17:29:45 mriedem ok yeah so the allocation ratios are per host,
17:29:49 mriedem so the limits are per host
17:29:55 mriedem so they go into the selection object yeah?
17:30:03 dansmith yeah, have to
17:30:15 mriedem and RequestSpec.limits is i guess just the same as the first host chosen
17:30:38 dansmith and filter properties
17:30:40 dansmith and limits
17:33:00 mriedem maybe this is an appropriate time to drop this in here https://review.openstack.org/#/c/499799/
17:33:41 mriedem removes 5% of the request spec TODOs
17:43:35 openstackgerrit Jackie Truong proposed openstack/nova master: Implement certificate_utils https://review.openstack.org/479949
17:46:16 openstackgerrit Eric Fried proposed openstack/nova master: Send Allocations to spawn https://review.openstack.org/511879
17:46:27 efried dansmith gibi I think I hit your concerns ^
17:59:30 openstackgerrit Jackie Truong proposed openstack/python-novaclient master: Microversion 2.54 - Add trusted_image_certificates https://review.openstack.org/500396
18:08:16 openstackgerrit Merged openstack/nova master: fix cleaning up evacuated instances https://review.openstack.org/510938
18:09:58 dansmith efried: sorry if I wasn't clear, but I don't think adding a whole new fixture just to mock that one thing makes sense,
18:10:12 dansmith I just wanted you to use MonkeyPatch in there instead of mock.start() and addCleanup()
18:11:17 dansmith efried: like this for example: https://github.com/openstack/nova/blob/master/nova/tests/unit/virt/test_virt_drivers.py#L96
18:22:36 gregwork is there a way to pass custom options to qemu via nova ?
18:22:48 gregwork such that when a guest starts up it starts with those extra options
18:28:17 artom gregwork, like literally custom qemu command line options? No.
18:28:47 mriedem artom: do you care about updating this newton change? https://review.openstack.org/#/c/467321/
18:29:01 mriedem artom: looks like it would need to cherry pick from https://review.openstack.org/#/c/482219/ in ocata
18:29:21 mriedem newton eol is tomorrow
18:29:31 artom mriedem, aha, thanks for the heads up
18:29:38 artom Yeah, lemme do that now
18:31:48 efried dansmith okay.
18:33:53 mriedem dansmith: want to put this in? https://review.openstack.org/#/c/507557/ - the change on stable/ocata is merged, which is what i think tony was waiting for
18:34:22 melwitt mriedem, dansmith: I've got a change up to remove a lot of old quotas code. the only thing I'm not 100% about is the Quotas object methods, I assume they can't be removed until a major version bump. https://review.openstack.org/#/c/511689
18:34:42 mriedem i've got that one starred, hadn't been through it yet though
18:34:58 dansmith mriedem: ack
18:35:02 gregwork artom: im trying to get qemu to spawn the guest with -mem-path /dev/hugetlbfs and -mem-prealloc as per my mellanox dpdk guide
18:35:04 mriedem and yeah i suppose you can't remove the versioned object methods w/o a major bump
18:35:12 dansmith yup
18:35:24 melwitt yeah, I wasn't sure if that's true only for remotables or all
18:35:24 dansmith if they're remotable, that is
18:35:27 gregwork artom: not sure how to pull this off
18:35:48 dansmith melwitt: non-remotables can be removed
18:35:49 dansmith melwitt: you'll know because the hash won't change
18:36:15 mriedem what if the quota engine code behind the remotable object method is removed?

Earlier   Later