Earlier  
Posted Nick Remark
#openstack-nova - 2022-06-13
06:51:11 gibi when cinder is installed
06:51:39 gibi that policy file needs to be copied to the policy.d of the nova
06:51:44 gibi to grant the access for cinder
08:31:56 gibi priteau: hi! thanks for the patch https://review.opendev.org/c/openstack/nova/+/845262 I'm +2 on it. Are you planning to backport this to stable branches too?
08:32:16 gibi bauzas: fyi ^^ a simple fix we agreed on last week in berlin ;)
08:32:49 opendevreview Takashi Kajinami proposed openstack/nova master: Retry attachment delete API call for 504 Gateway Timeout https://review.opendev.org/c/openstack/nova/+/845543
08:33:24 gibi sean-k-mooney: hi! Could you plug your +2 back to https://review.opendev.org/c/openstack/nova/+/829248 ? Thanks!
08:43:15 bauzas hello everyone
08:43:20 gibi Uggla: hi! I just started looking at your unshelve patch. Have you considered my comment about splitting it? https://review.opendev.org/c/openstack/nova/+/831507/11..13#message-9605cc5a2071898fa3da8d460761a3910f9bb55f
08:43:30 gibi bauzas: o/
08:43:36 bauzas gibi: hope you're good
08:43:59 gibi I'm on ~75% energy level
08:45:25 bauzas priteau: gibi: https://review.opendev.org/c/openstack/nova/+/845262 sent to the gate
08:45:31 gibi bauzas: thanks
08:45:42 bauzas agreed with you, we should backport it
08:45:43 gibi priteau: let me know your view on backporting. I can take it if you have not time for it
08:47:51 Uggla gibi, Hi. Yes I tried to split into 2 patches as you explained. But I had a lot of tests that failed. Mainly because az=None not handled correctly by the REST API part.
08:48:51 gibi Uggla: the first patch after the split should not alter the api behavior
08:49:10 Uggla gibi, trying to explain --> REST api and compute_api are "coupled". You need some code to handled the az=None case.
08:50:25 gibi ack. I think there should be a way to split it. But I haven't tried it so you have more info than me about the hardness of it
08:56:54 Uggla gibi, look at --> patchet 11 --> 12 is the attempt.
08:58:56 Uggla gibi, and the functional-py39 --> result.
08:59:10 Uggla gibi, https://zuul.opendev.org/t/openstack/build/7544a9e1f3804d068abcab1bcf199dc1
09:00:43 Uggla bauzas, gibi , so how was the summit ? Did you enjoy it ?
09:01:25 bauzas Uggla: yes and no, some Forum sessions were good while others were just presentations
09:01:49 bauzas at least it was productive discussions on hallways.
09:02:00 Uggla bauzas, did you meet operators as planned ?
09:07:10 bauzas yes
09:07:26 bauzas at the PTG, we won't unfortunately see them
09:07:39 bauzas it's a sad situation
09:08:13 bauzas I'd prefer operators and developers to be on the same venue
09:41:34 gibi Uggla: I think it is easy to fix the test failures in the split patches case https://review.opendev.org/c/openstack/nova/+/831507/comment/6d273ab6_17fa8e3f/
09:41:45 gibi Uggla: basically you redefined what new_az=None means
09:41:59 gibi so you have to adapt either the caller or the callee to translate
09:43:57 Uggla gibi, to be honest, I was lazy. I did no see the benefits to fix those tests in the first patch to then change them in the next one. :)
09:44:10 gibi the fix is not in the tests
09:44:19 gibi it is about how to split :)
09:44:27 gibi you need one extra line of code to support the splitting
09:44:51 gibi btw, in general patches > 1000 lines of change considered too big to review, hence my request to split
09:45:15 Uggla gibi, agree, I will try it again.
09:45:23 gibi I let you hints in the review
09:45:31 gibi s/let/left/
10:11:20 sean-k-mooney gibi: oh sure the pf mac patch
10:11:34 gibi sean-k-mooney: yepp that is gettin gold
10:11:36 gibi getting old
10:14:55 sean-k-mooney stephenfin: bauzas would either of ye care to be the second +2 on https://review.opendev.org/c/openstack/nova/+/829248 for gibi
10:15:06 gibi that would be much appreciated
10:15:29 sean-k-mooney im just looking at the nova status check https://review.opendev.org/c/openstack/nova/+/829248
10:16:14 sean-k-mooney do we want to mention the workaround option for FFU case
10:23:44 songwenping__ sean-k-mooney: do you have the lastest local.conf for both one controller node and two compute nodes deployed by devstack?
10:24:36 gibi sean-k-mooney: you mean in the upgrade check descrtiption?
10:24:36 sean-k-mooney songwenping: what do you mean by default your local.conf can basically be empty
10:24:57 sean-k-mooney songwenping: are you refering to in a ci job
10:25:17 sean-k-mooney gibi: https://review.opendev.org/c/openstack/nova/+/845262/2/nova/cmd/status.py#322
10:25:45 sean-k-mooney the status check shoudl take account of the workarounds config option to determin if its a warnign or error
10:26:05 sean-k-mooney and the message when it prints shoudl mention the workarounds config option too
10:26:47 songwenping sean-k-mooney: no, i'm plan to deploy develop env with one controller and two computes.
10:27:22 sean-k-mooney for FFU this might fail depending on when you run it
10:28:00 sean-k-mooney songwenping: oh you just want a refernce local.conf to use
10:28:08 songwenping yeah
10:28:30 sean-k-mooney i think i have one ya one sec
10:28:33 songwenping i donnot know the services to enable or disable
10:28:55 gibi sean-k-mooney: replied
10:33:31 sean-k-mooney songwenping: its really only on the compute that you need to overried the default services but ill paste the ones my ansible code generate
10:35:29 sean-k-mooney songwenping: https://paste.opendev.org/show/bBQ5w8E9neWknQ6fF3CO/
10:35:58 sean-k-mooney songwenping: those have mroe thigns set then you need to set but you can look at the enabled/disabeld services
10:36:36 sean-k-mooney songwenping: the other thing thats important for the comptue nodes is to ensure that
10:36:39 sean-k-mooney RABBIT_HOST="192.168.121.82"
10:36:40 sean-k-mooney RABBIT_PASSWORD="password"
10:36:42 sean-k-mooney RECLONE="True"
10:36:44 sean-k-mooney REMOTE_CEPH="True"
10:36:46 sean-k-mooney SERVICE_HOST="192.168.121.82"
10:36:48 sean-k-mooney SERVICE_PASSWORD="password"
10:36:53 sean-k-mooney the ip or the rabbit host and service host are set to the contoller
10:37:21 sean-k-mooney you proably dont want to have RECLONE=True" set by the way
10:38:20 sean-k-mooney im using these with ansibel automation and i have simple epo caching with rsync so i need to force devstack to checkout the correct branch so i have reclone=True to force that
10:38:49 songwenping sean-k-mooney: many thanks, great useful.
10:41:57 sean-k-mooney songwenping: those are just based on the gate jobs by the way. so if you ever want to recreate what a job does you can look in the logs and find the local.conf it used
10:43:48 songwenping sean-k-mooney: in the stack.sh.log?
10:45:03 sean-k-mooney not its there directly https://zuul.opendev.org/t/openstack/build/6f4ec842455e4231a659c7ac12fc5f7c/log/controller/logs/local_conf.txt
10:45:59 sean-k-mooney if that was a multi node job then you woudl also see a compute/logs/local.conf.txt
10:46:43 sean-k-mooney the local.conf is one of the files we capature and preserve in the log output dir
10:49:20 songwenping ok, thanks.
10:59:14 sean-k-mooney gibi: implying we supprot ffu in any way conviced me we should ignore my previous comment and put it down to a lack of morning coffee :)
10:59:41 gibi sean-k-mooney: FFU is hard
10:59:49 gibi without coffee it is even harder :D
11:00:53 gibi but yeah, if we want to talk about FFU then we need to start with testing it first
11:01:10 gibi as I'm not soo convinced that it can be done :)
11:01:23 gibi I mean can be FFU successfully
11:01:57 rmart04 Hey @sean-k-mooney hope you are well. Wondering if you might be able to provide some advice for some CPU profile pain?
11:07:03 rmart04 not strictly development I know :D
11:15:18 rmart04 I'll post the question just incase it piques your interest :D
11:15:36 rmart04 if I change the flags I'm going to break future live migrations? :/
11:15:36 rmart04 We're in the process of upgrading to C8Stream (OS Train) and noticed our crippled CPU profile (Skylake-Server-IBRS) we have been using across a couple of processor generations no longer works, nova-compute won't start. We get "invalid CPUinfo profile is not compatible with CPU". I'm guessing a microkernel update has changed the flags on the move from C7->C8 for our CascadeLake servers. Is there an easy way around this these days? I'm guessing
11:17:33 sean-k-mooney rmart04: just back with coffee reading back
11:17:49 opendevreview Balazs Gibizer proposed openstack/nova master: Refactor the nested if-else forest https://review.opendev.org/c/openstack/nova/+/845581
11:18:36 sean-k-mooney rmart04: this s almost certainly caused by the fact that tsx was disabled/removed by intel in a microcode
11:19:11 gibi Uggla: I made an attempt to transform out the nested if-else forest from the unshelve patch https://review.opendev.org/c/openstack/nova/+/845581
11:19:16 sean-k-mooney i belive the Skylake-Server-IBRS has tsx enabeld but the cascadelake cpus woudl have it disabeld by the new microcode in c8s
11:20:50 sean-k-mooney rmart04: you are currently using Skylake-Server-IBRS i would guess Skylake-Server-noTSX-IBRS will work

Earlier   Later