| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-30 | |||
| 13:18:42 | tosky | sean-k-mooney, gibi: we don't have jobs which starts from py27 and ends with py3*; the patch which backports the "don't install python2 library packages" has been backported to train a few hours ago, so grenade jobs should be fine for a final review (and merge) now | |
| 13:18:51 | gibi | sean-k-mooney, efried: I like the numa modeling proposal. thanks for crafting it | |
| 13:19:09 | gibi | tosky: ack, thanks | |
| 13:20:29 | tosky | gibi: afaik (gmann can provide a better answer), we don't support at all that py2->py3 scenario; if you want to test the train->master migration, just deploy train with py3 | |
| 13:20:30 | sean-k-mooney | tosky: awsome | |
| 13:21:00 | sean-k-mooney | tosky: that more because we dont have a good way of cleaning the packages | |
| 13:21:27 | gmann | yeah and do not have someone to do that | |
| 13:22:42 | sean-k-mooney | well we are also not sure if there could in be a difference in the rpc traffic somehow | |
| 13:23:11 | sean-k-mooney | we dont think there will be but that was one of the worries. e.g. the ovo we send over amqp could some how be incompatiable | |
| 13:23:27 | sean-k-mooney | i dont think that is the case but i know it was raised in the past | |
| 13:24:33 | sean-k-mooney | no one has reported upgrade issues at least so its untested in the gate but appears to work in reality | |
| 13:26:14 | gmann | yeah, other integration py2 job on train or older release along with py3 jobs can tell both py version works well and should not be issue on upgrade with py2 version too. but yes it is not tested on gate. | |
| 13:28:09 | gibi | stephenfin: if you can fix the funct test then I can +2 https://review.opendev.org/#/c/662522 | |
| 13:55:09 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Avoid PlacementFixture silently swallowing kwargs https://review.opendev.org/695180 | |
| 13:55:09 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Add a placement audit command https://review.opendev.org/670112 | |
| 14:00:13 | bauzas | gibi: I updated the audit command for fixing the tests | |
| 14:00:32 | bauzas | gibi: I also saw your other change for the PlacementFixture | |
| 14:00:39 | bauzas | as you want | |
| 14:01:56 | efried | stephenfin: Hah, "docs". | |
| 14:03:34 | efried | I fear there were never actually docs. But let me go refresh my memory on where they're translated over to actual PowerVM-isms (which *should* have docs... somewhere). | |
| 14:04:39 | efried | I don't think it would be super unreasonable for you to assign the work to the #openstack-powervm team to track that down. But only if you don't want it to get done. | |
| 14:04:54 | openstackgerrit | Merged openstack/nova-specs master: Add action event fault details https://review.opendev.org/699669 | |
| 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 | sean-k-mooney | in that case the only thing that will save us is commit history | |
| 14:20:51 | efried | some pretty mysterious stuff in there. | |
| 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 | efried | yeah, no. | |
| 14:21:48 | sean-k-mooney | am i hoping for too much | |
| 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 | [3] https://opendev.org/openstack/nova/src/branch/master/nova/virt/powervm/vm.py#L466-L473 | |
| 14:35:20 | efried | [2] https://opendev.org/openstack/nova/src/branch/master/nova/virt/powervm/vm.py#L442-L443 | |
| 14:35:20 | efried | [1] https://opendev.org/openstack/nova/src/branch/master/nova/virt/powervm/vm.py#L376 | |
| 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 | And we know those are all the allowable keys because [2] and [3]. | |
| 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: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 | "If something is failing to complete after 5 loops, surely that's an issue that bumping the value will only mask?" | |
| 14:58:16 | francoisp | stephenfin you put in a comment at nova/conf/compute.py, line 871: | |
| 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: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. | |