Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-06-19
15:54:29 bauzas jaypipes: roger
15:54:46 bauzas FWIW, I'll *still* be on PTO for 2 days this week
15:54:55 bauzas Tues-Wed
15:55:27 bauzas you're fully granted for making any joke about french people being always on vacations
15:55:41 bauzas I won't get offended
15:56:26 jaypipes bauzas: lol, no worries. enjoy the time off :)
15:56:50 bauzas jaypipes: edleafe: so, let's merge first the above before the scheduler-claims series, right?
15:57:16 bauzas I just want to make sure the above is blocking the other series like nested-rps or scheduler-claims
15:57:27 jaypipes bauzas: that is correct.
15:57:43 bauzas cool, then I'll be reviewing it very soon today
15:58:25 bauzas edleafe: FWIW, I haven't replied to your ML post because I agree with jaypipes's comments
15:58:38 bauzas and mriedem's nits, btw.
15:58:57 bauzas I was confused by you saying that the scheduler was calling the placement API for allocating :)
15:59:32 jaypipes bauzas: it *will* be. but doesn't yet.
15:59:43 bauzas yeah I know
15:59:53 bauzas but I was confused by the "current situation" name :p
16:02:18 edleafe bauzas: yeah, I meant the current *design* we had agreed upon, as compared to the new approach
16:03:19 edleafe bauzas: I had a mental concept of what this would look like when we were done.
16:03:31 edleafe bauzas: I'm not clear on where we're heading now.
16:06:29 mriedem edleafe: it's basically the same except some machinery changes - where filter scheduler calls placement with 1.4 today to get a list of filtered providers based on vcpu/ram/disk, we now call the allocation candidates API
16:07:05 mriedem we use the allocation candidates response to get our list of compute node objects to create HostState objects for filtering/weighing,
16:07:12 mriedem since we don't have concepts like affinity in placement yet
16:07:30 mriedem and we also use the allocation candidates response to PUT the allocation "claim" at the end on selected providers
16:08:36 mriedem so we might allocate some vcpu/memory_mb on a compute node resource provider, and some disk_gb on a shared storage provider
16:09:00 edleafe mriedem: sure, that's fine. But there is more to it than that, as I understood it. Placement will be returning information about the RPs, not just name/UUID. Originally that info was to replace HostState objects, but according to jaypipes today we now need both
16:09:26 mriedem edleafe: i don't know where/when/who ever said that we'd not need HostState objects anymore
16:09:34 mriedem removing their usage in the scheduler would be a huge refactor
16:09:42 dansmith actually,
16:10:06 dansmith I said we'd have to do some monkeywork to adapt what we get into hoststate objects so we could move on without that refactor having to happen synchronously
16:10:15 dansmith so, yeah.
16:10:53 mriedem ok, but we still pass host state objects to the filters and weighers right? and we have affinity/anti-affinity filters that we still need,
16:11:06 mriedem and i think we can agree we don't want to change all of those at the same time
16:11:23 dansmith for now yeah
16:11:37 dansmith eventually I think that refactor will need to happen,
16:11:40 edleafe mriedem: I had proposed adding the sub-resource UUIDs (for PCI, shared disk, etc) to the HostState object. That wasn't possible, I was told, because HostState is going away
16:11:41 mriedem plus the impending destructification of everyone's out of tree filters/weighers at the same time :)
16:11:41 dansmith but it'll be a lot of work
16:12:01 dansmith mriedem: for which I will shed no tears
16:12:07 mriedem dansmith: i know
16:12:08 dansmith but definitely need some early warning for that change
16:12:11 mriedem right
16:12:20 dansmith scheduler filters being the least smelly of out-of-tree things
16:12:39 mriedem edleafe: how is shared disk a sub-resource?
16:12:59 mriedem granted i haven't been following the nested RPs work
16:13:06 edleafe it's not nested
16:13:26 edleafe but it is information that the compute node has (or can get via aggs)
16:13:52 edleafe the problem that started this is how to claim resources for non-simple providers
16:14:17 mriedem sure, and the allocation candidates thing does that - it gives the list of allocation requests you can make
16:14:29 mriedem the client does some filtering/weighing to pick which one(s) it wants to use
16:14:51 edleafe mriedem: right, at the cost of a huge increase in response size
16:14:54 mriedem so we don't have to duplicate that logic in the filter scheduler to know this compute node RP is related to a shared storage disk RP via aggregate
16:15:08 edleafe mriedem: I was concerned about a large deployment with thousands of matching hosts
16:15:19 mriedem edleafe: weren't you in the camp saying response size wasn't a problem when we were debating GET vs POST for 1.4?
16:15:32 mriedem or was that request size
16:15:42 edleafe mriedem: orders of magnitude different
16:15:49 edleafe and yeah, it was requst
16:15:52 edleafe request, even
16:16:13 mriedem i agree we are going to need to limit some on the placement side,
16:16:20 mriedem we can't return 100K entries in the response
16:16:33 edleafe mriedem: which brings us full circle
16:16:48 edleafe placement cannot know which hosts to return, and which to ignore
16:16:51 mriedem i don't actually know what the limit is on http response body size
16:17:05 mriedem it's filtering on which to ignore
16:17:07 edleafe mriedem: that's where the paging discussion came up
16:17:16 mriedem we just need to put a limit on how many filtered RPs can be returned
16:17:53 edleafe mriedem: if 5000 hosts can satisfy the request, placement cannot determine which ones are returned and which are not
16:18:15 mriedem edleafe: we do that today with 1.4 right?
16:18:22 mriedem and before that with ComputeNode.get_all()
16:18:25 edleafe mriedem: not that I know of
16:18:26 dansmith mriedem: no limit, since you don't have to provide content-length
16:18:29 mriedem actually with 1.4 we don't limit at all probably
16:18:40 dansmith mriedem: today we just OOM the scheduler if we have too many hosts I think
16:18:45 mriedem but with ComptueNode.get_all(), pre-placement, it was 1000 by default i think
16:19:35 mriedem but maybe we don't, i thought we used the os_api_limit config somewhere in the db api
16:19:36 dansmith mriedem: people with 100k hosts today already pick very coarse-grained because they're on cellsv1, where they pick a cell before they pick a host, which is exactly like limiting to the top N results from placement,
16:19:44 dansmith except we *know* the top N results from placement are valid,
16:20:00 dansmith and we could schedule to a full cell and then get trapped today
16:21:16 jaypipes is this something we need to solve today?'
16:22:13 dansmith jaypipes: you want the sarcastic or real answer?
16:22:15 jaypipes I think it's interesting that people who complain about some of my code looking like "premature optimization" (traits cache, etc) are trying to predict the behaviour of this API call for a deployment of 100K nodes which nobody has.
16:22:47 jaypipes dansmith: it's about a 5-line change to gzip this shit over to the scheduler.
16:22:51 mriedem i guess i don't see where we use max_limit in the db api if the caller (compute api) didn't pass in the limit, so pre-placement filter scheduler (mitaka) would just do ComputeNode.get_all() and pull in everything as dan said
16:22:59 jaypipes dansmith: and it could handle tons of entries, frankly.
16:23:07 dansmith jaypipes: you needn't convince me, as you know :P
16:23:39 jaypipes dansmith: plus, we're talking about the same number of allocation requests as the number of entries returned today when there's a single provider of shared disk.
16:24:01 dansmith jaypipes: you needn't convince me, as you know :P
16:24:09 jaypipes I'm just venting, sorry.
16:24:22 dansmith jaypipes: you needn't convince me, as you know :P
16:24:58 edleafe jaypipes: mriedem was asking about some of the backstory behind the HostState removal stuff
16:30:29 openstackgerrit Merged openstack/python-novaclient master: Make --profile load from environment variables https://review.openstack.org/475251
16:35:53 openstackgerrit Matt Riedemann proposed openstack/nova master: Handle uuid in HostAPI.compute_node_get https://review.openstack.org/461532
16:35:53 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Handle uuids in os-hypervisors API https://review.openstack.org/471899
16:35:54 openstackgerrit Matt Riedemann proposed openstack/nova master: Use uuid for id in os-services API https://review.openstack.org/464280
16:35:54 openstackgerrit Matt Riedemann proposed openstack/nova master: Consolidate index and detail methods in HypervisorsController https://review.openstack.org/475458
16:36:08 mriedem melwitt: unit test comments addressed ^
16:43:43 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Handle uuids in os-hypervisors API https://review.openstack.org/471899
16:47:37 openstackgerrit Alex Szarka proposed openstack/nova master: Reduce code duplication https://review.openstack.org/347422
17:13:36 ckopper danpawlik: are you around? sorry for the radio silence but once you have a minute we could chat a bit about the `img_hide_hypervisor_id` patch and and how to proceed (i.e. do we need `hv_vendor_id`?)
17:32:51 mriedem gibi: i won't be able to make the notification meeting tomorrow, just fyi
17:34:11 openstackgerrit Merged openstack/nova master: Fix a wrong comment https://review.openstack.org/474400

Earlier   Later