| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-30 | |||
| 14:07:48 | gibi | bauzas: ack, I will look back after my call | |
| 14:10:17 | openstackgerrit | Merged openstack/os-vif master: move os-vif-ovs to be a non legacy job. https://review.opendev.org/701601 | |
| 14:10:18 | openstackgerrit | Merged openstack/os-vif master: Revert "[Follow Up] OVS DPDK port representors support" https://review.opendev.org/703672 | |
| 14:10:27 | sean-k-mooney | efried: am i wrong in thinking that all extra spec are ment to have a spec or at least a blueprint associated with them when added | |
| 14:10:50 | sean-k-mooney | efried: today we would also add docs and a release note to that list | |
| 14:11:04 | efried | sean-k-mooney: I don't recall a rule like that, but it's not a bad one. | |
| 14:11:06 | sean-k-mooney | but im wondering if those would be documented in the nova spec repo | |
| 14:11:32 | sean-k-mooney | efried: well its technically an api change even though its an unversioned one | |
| 14:11:59 | efried | You'll have to slap my five-years-ago wrist. | |
| 14:12:11 | sean-k-mooney | normally the accompany bigger features so they get pulled into a spec or blueprint by default | |
| 14:12:20 | efried | There certainly aren't in-repo docs for the powervm: extra specs. | |
| 14:13:25 | efried | or in the oot driver repo, for that matter. | |
| 14:13:39 | openstackgerrit | waleed mousa proposed openstack/os-vif master: [Follow Up] OVS DPDK port representors support https://review.opendev.org/705018 | |
| 14:14:31 | sean-k-mooney | so looks like it was intoduced in tree in ocata | |
| 14:14:33 | sean-k-mooney | https://github.com/openstack/nova-specs/blob/master/specs/ocata/approved/powervm-nova-compute-driver.rst | |
| 14:15:13 | sean-k-mooney | actully pike | |
| 14:15:25 | efried | took us a while | |
| 14:15:45 | efried | I don't think you'll find docs for the extra specs though. | |
| 14:16:06 | sean-k-mooney | its ther in queens too | |
| 14:16:29 | sean-k-mooney | look liek ye added feature each release for a few releases | |
| 14:16:48 | efried | yes | |
| 14:16:50 | efried | stephenfin: This is going to be a manual process (for someone) I'm afraid. | |
| 14:17:56 | sean-k-mooney | speaking of manual proces i better go update the spec repo with the implemented spec for train | |
| 14:18:09 | sean-k-mooney | there is a script to do that it just needs to be run | |
| 14:18:40 | sean-k-mooney | but ya no info in the spec repo. i guess sice it was out of tree there was no need | |
| 14:19:21 | efried | it just goes to show that the only consumer was internal anyway, and already knew what all that stuff meant. | |
| 14:19:44 | sean-k-mooney | when yw were working on it day to day | |
| 14:20:00 | sean-k-mooney | hopefully there are code comments for each of them | |
| 14:20:08 | efried | nope. | |
| 14:20:20 | efried | I never knew/understood all of them even when I was working on it day to day. | |
| 14:20:41 | efried | Very specialized knowledge for operators of a power data center. | |
| 14:20:51 | efried | some pretty mysterious stuff in there. | |
| 14:20:51 | sean-k-mooney | in that case the only thing that will save us is commit history | |
| 14:20:55 | efried | no | |
| 14:20:59 | efried | commit history won't help | |
| 14:21:11 | efried | why would commit history have documentation if we don't have documentation? | |
| 14:21:39 | sean-k-mooney | the commit that added it should at least explain what it does to soem degree | |
| 14:21:48 | sean-k-mooney | am i hoping for too much | |
| 14:21:48 | efried | yeah, no. | |
| 14:22:07 | efried | Maybe for newer ones that were added after the main blob was put in. | |
| 14:22:10 | sean-k-mooney | well then i second your suggest to punt this to #openstack-powervm | |
| 14:23:05 | sean-k-mooney | oh i ment the out of tree drivers git repo history not the nova one | |
| 14:23:15 | efried | yeah, I know what you meant. Same answer. | |
| 14:23:39 | sean-k-mooney | :) | |
| 14:24:01 | sean-k-mooney | im going to grab breakfast/lunch brb | |
| 14:29:32 | efried | Oh snap! stephenfin: turns out PowerVC (the $ product that sits on top of this) allows you to pass the extra specs through, and actually documented them: https://www.ibm.com/support/knowledgecenter/SSXK2N_1.4.4/com.ibm.powervc.standard.help.doc/powervc_pg_flavorsextraspecs_hmc.html | |
| 14:35:18 | sean-k-mooney | damb good fined. so ya powervm:dedicated_proc is cpu pinning like i guessed | |
| 14:35:20 | efried | As you probably already figured out, VMBuilder._ATTRS_MAP [1] is the list of extra specs the powervm driver pays attention to. | |
| 14:35:20 | efried | And we know those are all the allowable keys because [2] and [3]. | |
| 14:35:20 | efried | I think you'll find these are a subset of what's in the above doc; that's just because the in-tree driver is still behind the oot driver. For your purposes, just ignore the rest. | |
| 14:35:20 | efried | [1] https://opendev.org/openstack/nova/src/branch/master/nova/virt/powervm/vm.py#L376 | |
| 14:35:20 | efried | [2] https://opendev.org/openstack/nova/src/branch/master/nova/virt/powervm/vm.py#L442-L443 | |
| 14:35:20 | efried | [3] https://opendev.org/openstack/nova/src/branch/master/nova/virt/powervm/vm.py#L466-L473 | |
| 14:35:50 | efried | sean-k-mooney: I think it's actually a bit more complex than that. | |
| 14:36:08 | efried | I think dedicated proc means you get a whole physical processor. | |
| 14:36:20 | efried | whereas shared means you get a piece of one | |
| 14:36:21 | sean-k-mooney | well its pinnign with the isolate polciy in libvirt parlance | |
| 14:36:28 | efried | but I think you're pinned regardless. | |
| 14:36:48 | efried | because powervm can hard partition a proc | |
| 14:37:30 | sean-k-mooney | oh ok well it its basicaly hw:cpu_policy=dedicated + hw:cpu_thread_policy=isolate pre train | |
| 14:37:34 | efried | so you can have, like, 20 virtual procs off of a physical proc, but you can set a minimum guarantee. | |
| 14:37:39 | sean-k-mooney | at least the semantic meaning is the same | |
| 14:38:00 | efried | I suspect powervm ops would disagree with you, but I'm not knowledgeable enough to do so :P | |
| 14:38:18 | efried | Let me put it this way: if the semantic meaning were the same, we would have just mapped the existing extra specs. | |
| 14:38:35 | sean-k-mooney | are you sure about that :) | |
| 14:38:38 | efried | no | |
| 14:38:51 | sean-k-mooney | adding your own might have just been quicker | |
| 14:38:54 | efried | but pretty sure. | |
| 14:39:37 | sean-k-mooney | in anycase when this validation work is complete i think it would be workthseeing if we can normalise the extra specs | |
| 14:40:47 | efried | If we had all the dev resources in the world, sure. | |
| 14:40:55 | efried | realistically, I see no chance of that happening. | |
| 14:41:02 | sean-k-mooney | i dont think it will mater in all cacuse but the powervm:shared_weight seam a lot like the cpu:shares option the libvirt and vmware | |
| 14:41:07 | sean-k-mooney | ya i guess | |
| 14:42:06 | sean-k-mooney | anyway really food this time o/ stephenfin when you get a chance can you review https://review.opendev.org/#/c/703373/ in os-vif | |
| 14:58:16 | francoisp | hello lyarwood, stephenfin, doing code rework for https://review.opendev.org/#/c/669674/ and I have a question for you: | |
| 14:58:16 | francoisp | stephenfin you put in a comment at nova/conf/compute.py, line 871: | |
| 14:58:16 | francoisp | "If something is failing to complete after 5 loops, surely that's an issue that bumping the value will only mask?" | |
| 14:58:17 | francoisp | I understand we want do do away with the config option, and stick with a hard-coded value for max number of re-tries. | |
| 14:58:18 | francoisp | are you suggesting we use a lower value (ex.: max 3 retries) ? | |
| 15:28:37 | Sundar | Hello dansmith, sean-k-mooney: I am here if you have any questions. | |
| 15:31:42 | dansmith | Sundar: about what? the latest rev? I haven't gone through anything yet this morning, but was hoping efried was going to take the next pass through pretty soon | |
| 15:33:29 | efried | "pretty soon" yah. | |
| 15:34:05 | efried | stephenfin: sending https://review.opendev.org/#/c/682655/ | |
| 15:34:05 | efried | bauzas: I didn't give you a chance for another swing at ^ -- please lmk if you have issues. | |
| 15:34:41 | bauzas | oh cool | |
| 15:34:46 | bauzas | honestly, I trust you | |
| 15:35:14 | bauzas | if I have time, I'll leave a +1 for the posterity | |
| 15:35:18 | efried | cool | |
| 15:35:54 | efried | bauzas: did you get a chance to catch up on the discussion for the numa topo spec? | |
| 15:36:05 | bauzas | efried: unfortunately no | |
| 15:36:26 | bauzas | yesterday evening my time you mean ? | |
| 15:36:53 | efried | Yes, but summarized in the spec comments and an etherpad linked therefrom. No need to read the whole IRC log. | |
| 15:36:56 | sean-k-mooney | bauzas: efried sumerised it in the spec and linked to the conversation on irc and an ehterpad | |
| 15:37:22 | efried | bauzas: no real hurry (other than spec freeze in a couple weeks), but buzz me or sean-k-mooney if you have concerns or need clarification or whatever. | |
| 15:37:33 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Recalculate 'RequestSpec.numa_topology' on resize https://review.opendev.org/662522 | |
| 15:39:09 | stephenfin | gibi: fixed those functional tests ^ | |
| 15:39:09 | bauzas | sean-k-mooney: efried: no worries, i'll look at it | |
| 15:39:17 | stephenfin | got burned by my own refactoring work /o\ | |
| 15:39:25 | stephenfin | I really need to stop changing how those things work | |
| 15:39:25 | bauzas | and thanks for discussing this, even if I was parenting | |