| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-25 | |||
| 14:35:47 | johnthetubaguy | the sooner we get this out there, the sooner we get to fix the stuff that really affects people | |
| 14:35:47 | mdbooth | I know it's a bugfix, but if it gets any additional exposure from landing before FF that would be great. | |
| 14:38:22 | edleafe | johnthetubaguy: bauzas: from the RP spec: "As an example, let us say that a particular compute node has two quad-core Xeon processors, providing 8 total physical cores. Even though the cloud administrator may have set the cpu_allocation_ratio to 16 (the default), the compute node cannot accept requests for instances needing more than 8 vCPUs. So, while there may be 128 total vCPUs available on the | |
| 14:38:28 | edleafe | compute node, the min_unit would be set to 1 and the max_unit would be set to 8 in order to prevent unacceptable matching of resources to requests." | |
| 14:39:01 | edleafe | is this reasoning wrong? | |
| 14:40:00 | johnthetubaguy | so it has 16 threads, with hyperthreading I guess, which feels a better match to vCPU | |
| 14:41:05 | cdent | what max_unit is set to for vcpu is dependent on what the virt driver reports. if it is hyperthreading aware, it probalby reports more. | |
| 14:41:11 | edleafe | johnthetubaguy: so you're saying that the reasoning in the spec is wrong? | |
| 14:42:45 | dansmith | johnthetubaguy or bauzas: easy --verbose patch that is at the bottom of all the remaining cells/devstack/devstack gate changes: https://review.openstack.org/#/c/421228/ | |
| 14:43:47 | bauzas | dansmith: aye | |
| 14:43:57 | bauzas | I'm stuck anyway, I have now plenty of time for reviews | |
| 14:44:26 | dansmith | let me catch up for the morning and then we can look | |
| 14:44:29 | dansmith | at your stuff | |
| 14:45:27 | bauzas | dansmith: I'll need to send an email | |
| 14:51:57 | BobBall | edleafe: Which spec are you talking about there? I've just been chatting to one of the Xen developers and they believe its dangerous to over-commit in a single VM. Linux slows to a crawl (and may crash) and Windows definitely crashes. Apparently. | |
| 14:56:31 | sfinucan | johnthetubaguy, sdague: Easy Mox-mock patch that holding back a bug fix (ye've both reviews Mox-mock patches before :)) | |
| 14:57:31 | openstackgerrit | Takashi NATSUME proposed openstack/nova: Use ListOfIntegersField in oslo.versionedobjects https://review.openstack.org/423912 | |
| 14:59:25 | johnthetubaguy | dansmith: I am wondering about this, do we get away without needing a context manager there? https://review.openstack.org/#/c/319379/78/nova/compute/api.py@1800 | |
| 15:00:06 | cdent | BobBall: that was the original resource providers spec: http://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/resource-providers.html | |
| 15:00:18 | BobBall | ah ok | |
| 15:01:04 | BobBall | Thanks. | |
| 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: WIP: Collected release notes for Ocata CellsV2 https://review.openstack.org/424737 | |
| 15:17:46 | openstackgerrit | Dan Smith proposed openstack/nova: Move instance creation to conductor https://review.openstack.org/319379 | |
| 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 | 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 | |