| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-25 | |||
| 15:04:18 | bauzas | johnthetubaguy: cdent: edleafe: dansmith: just made a summary in the ML thread about the problem | |
| 15:04:26 | bauzas | with a silver bullet in it | |
| 15:04:49 | dansmith | johnthetubaguy: yeah, i think you might be right | |
| 15:05:07 | dansmith | johnthetubaguy: I'm surprised melwitt didn't do that though, so I'm wondering if she knows better | |
| 15:05:18 | dansmith | johnthetubaguy: I will queue a change though and then ask her when she's aroune | |
| 15:05:35 | johnthetubaguy | dansmith: cool, thanks | |
| 15:05:46 | melwitt | I think that's my bad. it was part of a bleary-eyed debugging session | |
| 15:06:27 | bauzas | cdent: you could defer to others for that, but I'd still love your thoughts | |
| 15:06:48 | dansmith | melwitt: ack, I'll fix | |
| 15:06:52 | cdent | bauzas: thanks for doing that, will look soon, in the midst of some debugging in devstack | |
| 15:07:28 | bauzas | cdent: edleafe: dansmith: johnthetubaguy: http://lists.openstack.org/pipermail/openstack-dev/2017-January/110938.html is the summary email | |
| 15:08:29 | bauzas | interesting, my English level is dropping fast | |
| 15:08:49 | bauzas | and we're at the middle of the week | |
| 15:09:15 | bauzas | but that email is awfully covered of mistakes so I apologize | |
| 15:12:52 | openstackgerrit | Artom Lifshitz proposed openstack/nova: Fix tag attribute disappearing in 2.32 and 2.37 https://review.openstack.org/424759 | |
| 15:13:44 | openstackgerrit | Artom Lifshitz proposed openstack/nova: Fix tag attribute disappearing in 2.33 and 2.37 https://review.openstack.org/424759 | |
| 15:17:46 | openstackgerrit | Dan Smith proposed openstack/nova: Move instance creation to conductor https://review.openstack.org/319379 | |
| 15:17:46 | openstackgerrit | Dan Smith proposed openstack/nova: WIP: Collected release notes for Ocata CellsV2 https://review.openstack.org/424737 | |
| 15:21:35 | bhagyashris | Vek : alex_xu: Hi, could you please review the patch [1] https://review.openstack.org/#/c/409644/ ? | |
| 15:28:00 | edleafe | BobBall: (reading back) Yes, concern about over-commmit was the reason that max_unit exists | |
| 15:28:17 | BobBall | *nod* I had mis-read. Thanks for confirming. | |
| 15:28:27 | edleafe | BobBall: Apparently some operators want to be able to override that. | |
| 15:28:39 | BobBall | Crazy people :) | |
| 15:29:14 | edleafe | BobBall: supposedly adding that sanity check will negatively affect them | |
| 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 | bauzas | if we set a cpu ratio to 9999.0, then the CoreFilter will be happy | |
| 15:49:23 | dansmith | I don't think that's right.. total should be the maximum available | |
| 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 | |