| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-25 | |||
| 14:23:07 | johnthetubaguy | aye | |
| 14:23:08 | cdent | bauzas: when a compute node reports inventory it reports a value from compute_node.vcpus. how is that calculated? | |
| 14:23:41 | cdent | (I'm trying to expand my understanding here, nothing else) | |
| 14:23:51 | bauzas | cdent: you mean the helper method, but how nova can know what cpus the node has ? | |
| 14:23:56 | bauzas | s/but/or | |
| 14:24:37 | cdent | I saying: there's a properly on the compute_node object called vcpus, which is set by update_from_virt_driver | |
| 14:24:39 | cdent | what does it mean? | |
| 14:27:03 | johnthetubaguy | bauzas: random thought, what if we change max unit to pCPU * allocation ratio? | |
| 14:27:22 | johnthetubaguy | edleafe: real world, feels like it only makes sense for test rigs and dev rigs | |
| 14:29:10 | edleafe | johnthetubaguy: what if we dump max_unit altogether? | |
| 14:29:21 | bauzas | johnthetubaguy: I'm pretty sure I would get a strong negative feedback on that approach | |
| 14:29:47 | johnthetubaguy | edleafe: it makes sense for some resources, just not all | |
| 14:30:12 | johnthetubaguy | edleafe: I think disk it was particularly useful for, from what I remember | |
| 14:31:48 | johnthetubaguy | hmm, I duno, it all feels very edge case, and there are work arounds if folks hit things | |
| 14:32:21 | bauzas | I'm feeling my patch is like a giant canary patch for spotting placement integration with nova | |
| 14:32:38 | bauzas | and being so close to FF makes me absolutely nervous | |
| 14:33:03 | bauzas | so we could spend yet another hours for discussing the good and the bad of operatoes | |
| 14:33:19 | bauzas | but the fact is that the landing window is reducing fast | |
| 14:34:12 | johnthetubaguy | bauzas: its also the most important patch to get all the lovelyness of placement exposed to our users, if that makes you feel better | |
| 14:34:24 | bauzas | i know | |
| 14:34:49 | bauzas | but that doesn't help if we're stuck | |
| 14:35:28 | johnthetubaguy | so the reality is, this is a big change, its going to be a bit bumpy | |
| 14:35:29 | mdbooth | Speaking of which, this is a not-insubstantial change which has been sitting a while: https://review.openstack.org/#/c/383859/ | |
| 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:35:47 | johnthetubaguy | the sooner we get this out there, the sooner we get to fix the stuff that really affects people | |
| 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: 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 | |