Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-08-07
13:31:44 gibi cdent, jaypipes, bauzas: https://review.openstack.org/491491
13:31:53 bauzas gibi: looking
13:34:27 bauzas gibi: unfortunately, that won't work
13:34:43 bauzas gibi: just one word : CachingScheduler (actually, two)
13:35:15 bauzas oh, fuck, nevermind
13:35:16 gibi bauzas: I might need more words than two to understand the reason
13:35:36 bauzas we're already under the USES_ALLOC_CANDIDATES conditional
13:35:53 bauzas gibi: CachingScheduler isn't using Placement
13:36:15 bauzas gibi: but on the other hand, it still runs the legacy filters
13:36:51 bauzas but like I said, we're under the conditional that asserts us that we already use placement
13:37:00 gibi OK, I think I see
13:37:21 gibi but then CoreFilter is still needed for the CachingScheduler. isn't it?
13:39:55 bauzas correct
13:40:05 bauzas well, if of course the operator wants it
13:40:15 bauzas any filter can be disabled
13:40:18 gibi sure
13:40:35 gibi it just mean an infinite overallocation on such resource
13:41:54 openstackgerrit Balazs Gibizer proposed openstack/nova master: Raise NoValidHost if no allocation candidates https://review.openstack.org/491491
13:42:28 jaypipes gibi: did you run all the func tests for that patch?
13:42:38 openstackgerrit Balazs Gibizer proposed openstack/nova master: Raise NoValidHost if no allocation candidates https://review.openstack.org/491491
13:44:03 gibi jaypipes: yes, I did and passed for me
13:44:15 gibi jaypipes: most of the functional tests using CachingScheduler as far as I know
13:44:31 jaypipes gibi: really? I don't think so...
13:46:04 gibi jaypipes: hm, my bad, it is the ChanceScheduler not the CacheScheduler
13:46:29 gibi s/CacheScheduler/CachingScheduler/
13:46:30 jaypipes gibi: if that's the case, that's a very serious bug in our functional tests.
13:46:39 cdent the PlacementFixture was turned on functional test-wide recently
13:46:56 gibi jaypipes: I'm trying to find the place it is set...
13:46:56 cdent sorry, meant to add a ? on that ^
13:47:01 jaypipes gibi: the ChanceScheduler is worthless.
13:49:42 bauzas jaypipes: people use chancescheduler for very simple functional tests involving the scheduler
13:49:54 bauzas only a very few use filterscheduler
13:51:58 jaypipes bauzas: since chance scheduler doesn't use placement, that's a mistake IMHO.
13:52:26 jaypipes we're not covering a large portion of our functional tests for no good reason.
13:53:22 bauzas jaypipes: if we run only one compute and want to boot one instance, why should we run filterscheduler and placement ?
13:53:22 gibi bauzas: do you know where the ChanceScheduler is set in the functional test env?
13:53:45 bauzas gibi: just look at self.flags(driver='chance_scheduler', group='scheduler')
13:53:45 jaypipes bauzas: because placement is now required.
13:54:34 jaypipes bauzas: we will never be able to get rid of the code in the compute node that does "claiming" if the chance scheduler is allowed to keep on existing. same for caching scheduler, frankly.
13:54:56 gibi bauzas: thanks. I always forget about the fact that it is chance_scheduler in the conf not ChanceScheduler
13:54:59 bauzas jaypipes: that's 2 different concerns IMHO
13:55:15 bauzas jaypipes: the main concerning one is that not all our drivers use placement
13:55:22 bauzas jaypipes: and that, I fully agree, should be fixed
13:55:41 dansmith we're going to fix that by deprecating caching scheduler
13:55:50 bauzas jaypipes: the second concern you express is that a large portion of our tests are not using filter_scheduler, but rather a dummy driver
13:55:50 jaypipes bauzas: no, I don't think the chance scheduler should be fixed at all. it should be removed. it does nothing at all.
13:56:01 bauzas jaypipes: that second concern is not a big deal to me
13:56:03 dansmith I dunno about chance scheduler, but I'd kinda expect the same
13:56:29 jaypipes bauzas: why is that second concern not a big deal to you? we're missing a huge % of coverage because of this.
13:56:37 bauzas dansmith: jaypipes: well, I personnally think that having different drivers is good for nova
13:56:52 jaypipes bauzas: yeah, I don't.
13:56:54 bauzas dansmith: jaypipes: and I expressed my idea of having the same input data for all drivers
13:57:12 bauzas just the scheduler algorithm should be different
13:57:27 dansmith having a completely ridiculous scheduler (chance) is not useful just to have an alternate option, IMHO
13:57:57 bauzas dansmith: well, I know some operators that use it :)
13:58:03 dansmith and the reason to have the cachingscheduler should go away when we're claiming in the scheduler, so... no real reason to keep tht either
13:58:14 dansmith bauzas: and? :)
13:58:27 jaypipes bauzas: the caching scheduler doesn't implement a different "algorithm". it implements a different storage mechanism and a different behaviour in responding to the instance update events.
13:58:44 bauzas I mean, filter scheduler being O(n2), some people tend to prefer other in-tree
13:59:09 bauzas jaypipes: I agree
13:59:53 bauzas jaypipes: let me rephrase, I just think that all drivers should by default get the list of hosts to verify by calling placement
13:59:56 jaypipes bauzas: what do you think the caching scheduler's big O notation is?
14:00:03 bauzas the same
14:00:07 jaypipes right.
14:00:15 bauzas but chance isn't
14:00:29 jaypipes chance doesn't do anything at all.
14:00:35 edleafe Scheduler subteam running now in #openstack-meeting-alt
14:00:43 mriedem o/
14:00:48 jaypipes bauzas: it doesn't even consider if a compute has room for the workload.
14:00:58 bauzas jaypipes: it does ONE thing, picking a host
14:01:04 bauzas jaypipes: the rest is done by the compute claim
14:01:16 bauzas that's a quick scheduler at least
14:01:25 bauzas if you are enough spaced
14:01:26 dansmith heh
14:01:38 jaypipes bauzas: err, you and I have different ideas of efficiency I guess.
14:01:46 bauzas yeah, I know, it's orthogonal to what we do
14:02:03 jaypipes bauzas, dansmith: sched meeting in meeting-alt
14:02:03 bauzas I'm just describing *why* people use it
14:03:07 dansmith bauzas: can you find any reference to support your claim that some people use chance successfully and recommend it in anything other than toy environments?
14:03:31 bauzas dansmith: unfortunately, only hallways talks
14:03:39 dansmith the only such mention on the first page of google is a RAX presentation from 2013 that says "filter scheduler is the only legit one"
14:04:22 bauzas anyway, I'm not particularly attached to chance_scheduler
14:04:29 bauzas it's even broken if you use ironic
14:04:33 stephenfin cdent: https://review.openstack.org/#/c/490952/ is pretty much done, yeah. All that needs to be checked if if I've missed anything from the import process
14:04:59 dansmith bauzas: oh okay, seems like you're arguing to keep maintaining it
14:05:01 bauzas I'm just trying to explain that I want to make sure we keep a clear separation in between what placement gives to drivers, and how driver work
14:05:28 bauzas dansmith: sorry, I'm unclear, I'm just giving food for thoughts about why we have it in-tree
14:05:47 bauzas we could outsource chance_scheduler
14:06:08 bauzas if we make clear the fact that it gets a list of RPs provided by Placement
14:06:20 bauzas it == the scheduler driver interface
14:06:28 mriedem the chance scheduler shouldn't even be asking placement for anything
14:06:37 mriedem it sets a flag for that (or doesn't set it rather)
14:06:40 dansmith I don't know what outsource means in this context
14:06:46 bauzas dansmith: out-of-tree
14:06:51 dansmith mriedem: well, the problem is it won't claim
14:07:02 dansmith mriedem: so if we have it in tree it needs to at least do that
14:07:14 mriedem dansmith: claim where? the scheduler?
14:07:20 mriedem neither does the caching scheduler
14:07:25 dansmith mriedem: right, same issue
14:07:37 mriedem why is that a problem? that was intentional

Earlier   Later