| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-25 | |||
| 15:29:40 | andreykurilin | stevemar: it looks like you can remove your -W to g-r patch:) | |
| 15:41:30 | andreas_s | Hi adreznec, quick question regarding nova-powervm devref creation | |
| 15:41:38 | andreas_s | adreznec, you have your config options defined here: https://github.com/openstack/nova-powervm/blob/master/doc/source/devref/usage.rst | |
| 15:42:00 | andreas_s | adreznec, have those been autogenerated somehow, or did yo create those tables by hand? | |
| 15:42:19 | andreas_s | I'm trying to achieve something similar for the nova-dpm project... | |
| 15:42:27 | bauzas | edleafe: BobBall: crazy people can be RAX | |
| 15:42:38 | bauzas | given they don't use the CoreFilter | |
| 15:43:52 | adreznec | andreas_s: I believe thorst_ built that set of documentation. Not sure what his exact steps were - do you remember thorst_? | |
| 15:44:12 | thorst_ | andreas_s: unfortunately, I did it all by hand. | |
| 15:44:16 | thorst_ | so it could be out of date. | |
| 15:44:37 | BobBall | bauzas: Only crazy if they offer flavours with more CPUs than the minimum number on their hosts? | |
| 15:44:43 | andreas_s | thorst_, adreznec ok thanks - maybe I'll find a way to automate that a bit.. | |
| 15:45:06 | thorst_ | andreas_s: let us know if you get it automated...I'd like to use that :-) | |
| 15:45:16 | sfinucan | pkoniszewski: If you want to fix this up quickly, I can +2 https://review.openstack.org/#/c/410817/5 | |
| 15:45:33 | andreas_s | thorst_, sure | |
| 15:45:44 | pkoniszewski | sfinucan: sure, thanks! | |
| 15:45:57 | dansmith | bauzas: I don't understand the problem in your email | |
| 15:46:31 | bauzas | dansmith: sorry, like I said, my English level in that email is just terrible | |
| 15:46:42 | bauzas | dansmith: let me restate the problem I spotted | |
| 15:46:53 | dansmith | bauzas: I get that max_unit causes some slightly different behavior? | |
| 15:47:00 | bauzas | dansmith: yup | |
| 15:47:18 | bauzas | dansmith: for example | |
| 15:47:24 | dansmith | max_unit is the maximum size of any given allocation of that resource type, yes? | |
| 15:47:29 | bauzas | dansmith: say an instance with a flavor of 2 vCPUs | |
| 15:48:00 | bauzas | dansmith: max_unit is the max resource class amount the provider supports | |
| 15:48:10 | bauzas | in its inventory | |
| 15:48:12 | bauzas | eg. | |
| 15:48:26 | dansmith | o.O | |
| 15:48:28 | bauzas | a compute exposing 1 CPU | |
| 15:48:35 | bauzas | will have max_unit=1 | |
| 15:48:40 | bauzas | like the FakeDriver | |
| 15:48:45 | bauzas | I mean the SmallFakeDriver | |
| 15:49:05 | bauzas | now, count an instance with a flavor of 2 vcpus | |
| 15:49:23 | dansmith | I don't think that's right.. total should be the maximum available | |
| 15:49:23 | bauzas | if we set a cpu ratio to 9999.0, then the CoreFilter will be happy | |
| 15:49:32 | dansmith | I think max_unit is the largest single allocation, and min_unit is the smallest | |
| 15:49:46 | dansmith | so if you want to not let someone request 1MB of RAM, for example, min_unit might be 64 | |
| 15:49:54 | bauzas | dansmith: lemme show you the code | |
| 15:50:05 | openstackgerrit | Pawel Koniszewski proposed openstack/nova: Add new configuration option live_migration_scheme https://review.openstack.org/410817 | |
| 15:50:11 | dansmith | https://github.com/openstack/nova/blob/master/nova/objects/resource_provider.py#L656-L665 | |
| 15:50:15 | dansmith | I'm looking at that ^ | |
| 15:51:07 | bauzas | dansmith: see how we report it per compute https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L94 | |
| 15:51:24 | bauzas | I mean, L95 rather | |
| 15:51:25 | dansmith | right, | |
| 15:51:37 | bauzas | so take my example | |
| 15:51:46 | bauzas | a driver reporting 1 VCPU | |
| 15:51:57 | bauzas | and an instance asking 2 vCPUs | |
| 15:52:26 | bauzas | if we use the allocation ratio of 999.0 then the compute will satisfy the request per the CoreFilter rules | |
| 15:53:15 | bauzas | https://github.com/openstack/nova/blob/master/nova/scheduler/filters/core_filter.py#L47 | |
| 15:53:23 | dansmith | you're saying that max_unit isn't scaled by allocation ratio, right? | |
| 15:53:27 | dansmith | (effectively) | |
| 15:54:30 | edleafe | bauzas: lines 54-56 are what I'm looking at | |
| 15:54:47 | cdent | dansmith: yes, and the questions are whether that is correct or not, and even if it not correct, if deprecation of some kind is required to deal | |
| 15:55:11 | bauzas | dansmith: wait, I think I'm puzzled | |
| 15:55:20 | dansmith | cdent: so the change from what we have now is that any one instance can't overcommit the host, effectively | |
| 15:55:21 | edleafe | I thought the issue was for operators who disabled CoreFilter | |
| 15:55:29 | cdent | dansmith: yes | |
| 15:55:44 | dansmith | cdent: like if the host has 1 vcpu to give, then you can have $allocation_ratio instances there, but not a multi-vcpu instance | |
| 15:55:47 | edleafe | They can currently put an 8VCPU request on a 2 VCPU host | |
| 15:56:02 | edleafe | But they won't be able to now, because of max_unit | |
| 15:56:08 | mdbooth | artom vladikr: volume_id in connection_info came up in review the other week, no? | |
| 15:56:16 | dansmith | edleafe: which is kinda what max_unit is for | |
| 15:56:23 | edleafe | dansmith: agreed | |
| 15:56:42 | mdbooth | artom vladikr: I'm currently doing a trawl of cinder volume drivers, and so far I've found at least 1 which doesn't set it. | |
| 15:56:44 | edleafe | dansmith: but bauzas and johnthetubaguy point out that that's a change w/o deprecation | |
| 15:56:47 | artom | mdbooth, yeah, you said it was a bad idea | |
| 15:56:48 | dansmith | edleafe: right now we just set it to the max, assuming a sane default, but we could change that later if someone has a good reason to allow such a thing | |
| 15:56:57 | mdbooth | artom vladikr: It's all very ad-hoc | |
| 15:57:06 | bauzas | what the hell | |
| 15:57:12 | artom | mdbooth, and then I went and re-checked with traget_dev/device_name, and it turns out that it works | |
| 15:57:15 | dansmith | edleafe: yeah, I can kinda see that, but.. it's also not very smart | |
| 15:57:31 | artom | mdbooth, my previous testing must have been as ad-hoc as colume id in cinder :) | |
| 15:57:33 | mdbooth | artom: Awesome. Wasn't sure what the resolution was, just thought I'd throw in a data point :) | |
| 15:57:47 | edleafe | dansmith: ok, so we have "bonkers", "crazy people", and "not very smart" to describe that | |
| 15:57:57 | edleafe | dansmith: you win the prize for most polite | |
| 15:57:59 | dansmith | edleafe: artom cdent: If someone had a problem with this, we could allow setting insanity_mode=on, which would report max_unit=N*allocation_ratio | |
| 15:58:18 | dansmith | edleafe: I'd like to change my answer to "fucking stupid" | |
| 15:58:49 | cdent | laaaaaadies and gentleman in a last minute change, dansmith wins | |
| 15:59:01 | bauzas | we don't use CoreFilter in the default list of filters | |
| 15:59:04 | bauzas | soooooo great | |
| 15:59:21 | dansmith | bauzas: that's not news, is it? | |
| 15:59:30 | bauzas | it is to me | |
| 15:59:38 | bauzas | I thought the gate was special | |
| 15:59:55 | bauzas | but that we allowed corefilter by default | |
| 16:00:01 | bauzas | I'm utterly surprised | |
| 16:00:35 | bauzas | so I'm just discovering that we *never* verified in Newton the CPU resources | |
| 16:00:41 | bauzas | unless you explicitely asked for | |
| 16:01:09 | bauzas | because if so, the CoreFilter would deny like the placement engine | |
| 16:01:20 | bauzas | that's even worst ! | |
| 16:01:28 | bauzas | holy shit | |
| 16:02:04 | bauzas | pardon my language | |
| 16:02:15 | bauzas | dansmith: ^ | |
| 16:02:32 | edleafe | bauzas: at least curse in French | |
| 16:02:45 | bauzas | so, just to be clear, lemme restate for the audience | |
| 16:02:47 | dansmith | even worse in what way? that it's a change? | |
| 16:03:07 | bauzas | in Newton, we totally accept that we can return a destination that doesn't satisfy the vCPU requirements | |
| 16:03:31 | bauzas | that's worst because that's changing the scheduler behaviour | |
| 16:03:48 | edleafe | Returning a destination is an implementation detail, not a behavior | |
| 16:04:09 | bauzas | placing an instance on a target is a behavioural choice | |
| 16:04:15 | dansmith | bauzas: but the whole point of placement is making better decisions right? | |