Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-06-19
14:27:42 bauzas hah
14:27:57 bauzas she's actually already asking me when she can drive
14:28:14 openstackgerrit Merged openstack/nova master: Amend api-ref for multiple networks request https://review.openstack.org/472733
14:28:20 bauzas she's almost 7, I was just shocked to tell her only 8 years last
14:28:59 edleafe bauzas: Mika turns 18 next month, and is off to university in August
14:29:05 edleafe scary
14:29:19 bauzas oh man, I so understand you
14:39:36 openstackgerrit Gábor Antal proposed openstack/nova master: Transform instance.rebuild-scheduled notification https://review.openstack.org/473929
14:44:57 openstackgerrit Gábor Antal proposed openstack/nova master: Transform instance.rebuild_scheduled notification https://review.openstack.org/473929
14:48:35 cfriesen has anyone ever talked about throttling the number of simultaneous deletion operations? we're seeing problems due to DB timeouts if you delete 100+ instances at the same time.
14:49:25 gabor_antal bauzas would you please review my patch at https://review.openstack.org/#/c/460029/? It already has +2 from sfinucan.
14:50:26 bauzas gabor_antal: sure
14:52:04 gabor_antal bauzas: thanks! :)
15:08:57 efried gabor_antal bauzas Doesn't notify_about_instance_usage send legacy notification? Do we really want that?
15:09:56 efried Whoops, sorry, I'm looking at it backwards. Disregard.
15:12:17 efried Perhaps we should consider making a context manager for versioned notifications, like gibi did for legacy here: https://review.openstack.org/#/c/437222/9/nova/compute/utils.py
15:16:00 gibi efried: that can be useful but I don't think that is a must
15:18:54 mriedem alex_xu: i'm not sure what you're asking for here https://review.openstack.org/#/c/464280/16/nova/api/openstack/compute/schemas/services.py@60
15:47:44 openstackgerrit Stephen Finucane proposed openstack/nova master: Use plain routes list for os-cells endpoint instead of stevedore https://review.openstack.org/474869
15:47:45 openstackgerrit Stephen Finucane proposed openstack/nova master: Use plain routes list for os-tenant-networks instead of stevedore https://review.openstack.org/474475
15:47:45 openstackgerrit Stephen Finucane proposed openstack/nova master: Use plain routes list for os-networks instead of stevedore https://review.openstack.org/474463
15:47:46 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove multiple create from stevedore https://review.openstack.org/474909
15:47:46 openstackgerrit Stephen Finucane proposed openstack/nova master: Use plain routes list for os-cloudpipe endpoint instead of stevedore https://review.openstack.org/474116
15:47:47 openstackgerrit Stephen Finucane proposed openstack/nova master: Use plain routes list for os-remote-consoles instead of stevedore https://review.openstack.org/474930
15:47:47 openstackgerrit Stephen Finucane proposed openstack/nova master: Use plain routes list for os-quota-classes endpoint instead of stevedore https://review.openstack.org/461641
15:49:53 openstackgerrit Stephen Finucane proposed openstack/nova master: Use plain routes list for os-cells endpoint instead of stevedore https://review.openstack.org/474869
15:49:54 openstackgerrit Stephen Finucane proposed openstack/nova master: Use plain routes list for os-networks instead of stevedore https://review.openstack.org/474463
15:49:54 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove multiple create from stevedore https://review.openstack.org/474909
15:49:55 openstackgerrit Stephen Finucane proposed openstack/nova master: Use plain routes list for os-remote-consoles instead of stevedore https://review.openstack.org/474930
15:50:50 openstackgerrit Jay Pipes proposed openstack/nova master: placement: produce set of allocation candidates https://review.openstack.org/473377
15:50:50 openstackgerrit Jay Pipes proposed openstack/nova master: placement: support GET /allocation_candidates https://review.openstack.org/475448
15:51:07 jaypipes edleafe, dansmith, mriedem, bauzas: ^^
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()

Earlier   Later