| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-07 | |||
| 15:49:23 | bauzas | cachingscheduler is a totally different story | |
| 15:49:25 | mriedem | dansmith: we should be able to test that before removal | |
| 15:49:54 | bauzas | we want to remove caching because we do claims only in filter, right? | |
| 15:50:04 | mriedem | anyway, we're not removing those today, if we want to signal i think that's fine | |
| 15:50:06 | dansmith | mriedem: who is going to test that at scale do you think? | |
| 15:50:09 | bauzas | jaypipes: can't we imagine to have caching scheduler to claim as well ? | |
| 15:50:29 | dansmith | OSIC would have been an option, but tbh, I dunno who is likely to do it by the time we need to know in queens | |
| 15:50:34 | bauzas | jaypipes: you said you were blocked when untangling that, but do you think it's doable tho ? | |
| 15:50:45 | mriedem | dansmith: well, i know mirantis + intel has done some scale testing in the past, i don't know if those resources are still available, otherwise i'd like to try and see if huawei can do that, | |
| 15:50:55 | mriedem | because huawei public cloud is using the caching scheduler | |
| 15:50:57 | jaypipes | bauzas: caching scheduler would need to stop using the cached compute node information it has and instead call ComputeNodeList.get_all_by_uuid(), which would make the caching scheduler === the filter scheduler. | |
| 15:51:00 | dansmith | mriedem: okay well, that'd be cool | |
| 15:51:49 | bauzas | jaypipes: caching has different input than filterscheduler, but we could still claim the result right? | |
| 15:52:00 | dansmith | bauzas: not really | |
| 15:52:13 | dansmith | bauzas: if it's not getting allocation candidates, it is missing some of what it needs | |
| 15:52:21 | dansmith | bauzas: we could make it work, but it would be wonky | |
| 15:52:31 | bauzas | I see | |
| 15:52:34 | jaypipes | dansmith: and not worthwhile, imho. | |
| 15:52:36 | dansmith | bauzas: or we'd have to sift through the results of /ac to find the thing we chose based on our cached data | |
| 15:52:39 | dansmith | jaypipes: agreed | |
| 15:52:48 | bauzas | so, yeah, benchmarks | |
| 15:53:07 | dansmith | IIRC, the reason to keep caching scheduler after we moved to placement was because we weren't claiming and thus still making bad (cached) decisions in high traffic | |
| 15:53:23 | bauzas | I need to disappear for family business, but I will watch out thec convo | |
| 15:53:28 | bauzas | dansmith: you're correct | |
| 15:53:29 | dansmith | so claiming now should resolve that I think, and I would expect the gains of being able to run multiple schedulers would be more win than loss | |
| 15:53:30 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Add a prelude section for Pike https://review.openstack.org/491424 | |
| 15:53:50 | bauzas | dansmith: right, I just mentioned that in the prelude ^ | |
| 15:54:01 | bauzas | dansmith: we can now run multiple scheduler workers | |
| 15:54:10 | bauzas | THAT is the big improvement | |
| 15:54:30 | dansmith | I would expect to be able to brute-force scale the scheduler as high as you want with just that change alone | |
| 15:54:40 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: replace chance with filter scheduler in func tests https://review.openstack.org/491529 | |
| 15:54:45 | bauzas | scale out you mean ? | |
| 15:54:54 | bauzas | or scale up the load ? | |
| 15:55:02 | dansmith | bauzas: scale it to as high of a throughput as you need by scaling out yes | |
| 15:55:20 | bauzas | k | |
| 15:55:26 | bauzas | I agree | |
| 15:55:28 | gibi | we can easily remove chance from the func test. here is the patch: https://review.openstack.org/491529 | |
| 15:56:13 | bauzas | yeah | |
| 15:56:21 | bauzas | not a big deal | |
| 15:56:35 | bauzas | anyway I need to leave | |
| 15:56:38 | bauzas | ++ | |
| 15:56:38 | cdent | gibi: nice | |
| 15:56:46 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hardware: Flatten functions https://review.openstack.org/367470 | |
| 15:56:47 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Standardize '_get_XXX_constraints' functions https://review.openstack.org/385071 | |
| 15:56:47 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Rename '_numa_get_constraints_XXX' functions https://review.openstack.org/385072 | |
| 15:56:48 | openstackgerrit | Stephen Finucane proposed openstack/nova master: De-duplicate _numa_get_flavor_XXX_map_list https://review.openstack.org/385074 | |
| 15:56:55 | bauzas | FWIW we don't even need RetryFilter | |
| 15:57:01 | bauzas | if we are singlehost | |
| 15:57:53 | sdague | so... is someone going deprecate chance completely? | |
| 15:58:01 | dansmith | sdague: and caching | |
| 15:58:10 | sdague | sure, that too | |
| 15:58:10 | dansmith | we need to deprecate both in pike | |
| 15:58:16 | dansmith | we can remove one or both when appropriate | |
| 15:58:29 | sdague | ok, is that up for review? we're in rc week | |
| 15:58:55 | jaypipes | gibi: why the change from 1 vcpu to 2 vcpus? that's weird.. | |
| 15:59:20 | dansmith | sdague: are you asking if you can do it? | |
| 15:59:24 | gibi | jaypipes: because there is resize to same host where the allocations are doubled up | |
| 15:59:36 | gibi | jaypipes: so at least 2 vcpu is needed | |
| 15:59:41 | dansmith | gibi: yeah | |
| 15:59:47 | jaypipes | gibi: guh, gotcha. | |
| 15:59:49 | dansmith | makes sense, I had to do that in some of the tests as well | |
| 16:00:04 | dansmith | jaypipes: this is the max_unit thing I was talking about with moves | |
| 16:00:05 | dansmith | jaypipes: that is going to piss people off | |
| 16:00:12 | dansmith | because allocation_ratio won't apply to single-host moves | |
| 16:00:46 | dansmith | migration uuid will fix that | |
| 16:00:50 | jaypipes | dansmith: yeah, understood. not sure it's the end of the world, though. | |
| 16:00:59 | cdent | migration uuid will fix everything! | |
| 16:01:02 | dansmith | eff yeah it's the end of the world | |
| 16:01:06 | jaypipes | :) | |
| 16:01:11 | dansmith | I have a single-node cloud at home! | |
| 16:01:26 | gibi | dansmith: only one? ;) | |
| 16:01:52 | dansmith | gibi: many nodes, but only one in the openstack deployment :) | |
| 16:03:17 | mnaser | i'm going over the scheduler code and i've realized that we're pretty much sending instances to our biggest hypervisors and the smaller ones remain empty. the ram weighter by default weighs based on free memory, which means that a hypervisor with 128gb memory and all of it free will have less priority than one that has 384gb with 192gb free | |
| 16:03:39 | mnaser | arguably.. shouldnt it be based on a percentage? | |
| 16:04:03 | mnaser | https://github.com/openstack/nova/blob/master/nova/scheduler/weights/ram.py | |
| 16:04:19 | jaypipes | mnaser: perhaps use the num instances weigher instead? | |
| 16:04:43 | dansmith | or weigh the num_instances higher than the ram one | |
| 16:04:49 | dansmith | mnaser: some people want to pack first | |
| 16:04:50 | jaypipes | mnaser: nm, there is no such thing :( | |
| 16:04:52 | dansmith | because windows licenses | |
| 16:05:10 | mnaser | dansmith: packing would still work with -1.0 | |
| 16:05:13 | dansmith | jaypipes: there's something like that pretty sure | |
| 16:05:29 | mnaser | https://github.com/openstack/nova/tree/master/nova/scheduler/weights | |
| 16:05:35 | mnaser | i dont see a num_instances on | |
| 16:05:38 | mriedem | stephenfin: where does this come from? https://review.openstack.org/#/c/490952/3/doc/source/admin/security-groups.rst | |
| 16:05:54 | mnaser | there's a fitler but not a weighter | |
| 16:05:58 | stephenfin | mriedem: cli-nova-manage-projects-security.rst | |
| 16:06:01 | stephenfin | (I think | |
| 16:06:03 | jaypipes | mnaser: yeah :( | |
| 16:06:03 | mriedem | oh nvm https://github.com/openstack/openstack-manuals/blob/stable/ocata/doc/admin-guide/source/cli-nova-manage-projects-security.rst | |
| 16:06:04 | mriedem | yeah | |
| 16:06:18 | dansmith | mnaser: yeah, that's what I'm thinking of, heh | |
| 16:06:47 | mnaser | cause if it was percentage based, the ability to pack vs distribute would still work, but would be based on usage percentage rather than just absolute free memory | |
| 16:07:24 | mnaser | i'm just slightly annoyed because i remember very clearly reading somewhere online (ML?) that someone had this exact issue and they dealt with it somehow but i figured "we won't deal with that" and here i am | |
| 16:08:17 | dansmith | man I really thought we had more weighers | |
| 16:09:40 | mriedem | stephenfin: so on https://review.openstack.org/#/c/490952/ I think we should have those various volume attach troubleshooting docs | |
| 16:10:18 | jaypipes | mnaser: can't believe I'm suggesting this, but you could adapt the existing RAM weigher and make it work on percentages instead of raw capacity numbers. | |
| 16:10:40 | jaypipes | mnaser: else submit a wishlist bug for one of us to get to. | |
| 16:10:57 | jaypipes | mnaser: like dansmith I'm kinda surprised such a thing doesn't already exist :( | |
| 16:11:57 | mriedem | stephenfin: and maybe leave todo comments for combining the quotas pages | |