Earlier  
Posted Nick Remark
#openstack-nova - 2020-01-30
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
15:40:16 bauzas gibi: stephenfin: efried: we have this very old cmd that would help ops, if you like getting it a swing https://review.opendev.org/#/c/670112/
15:40:32 bauzas mriedem would be surprised if we eventually merge it :p
15:40:37 sean-k-mooney after backporting acrouss 4 release im not sure you can resist it
15:41:19 sean-k-mooney the sad part is each refactoring does make them better
15:42:46 stephenfin bauzas: Oh, that looks hairy. Can you ask me Monday once FOSDEM's behind me? :)
15:43:04 bauzas stephenfin: well, if you're not hit by the Coronavirus, of course :D

Earlier   Later