Wednesday, 2022-03-02

gmannbauzas: gibi easy one to avoid grenade-skip job running on doc/test patches https://review.opendev.org/c/openstack/nova/+/83122900:34
gmannmelwitt: sean-k-mooney ^^ if any one of you around 00:34
melwittgmann: I'm curious why *nova-base-irrelevant-files and not *policies-irrelevant-files? shouldn't nova/policies/ changes be tested with the skip level upgrade job?00:53
melwittit also shows as merge conflict01:02
gibigmann, melwitt: I agree with melwitt, I think we need to trigger on policy changes too06:48
bauzasgibi: gmann: melwitt: dansmith: me too07:47
bauzaseasy change FTW07:47
opendevreviewMerged openstack/nova stable/wallaby: Migrate RequestSpec.numa_topology to use pcpuset  https://review.opendev.org/c/openstack/nova/+/82787109:28
opendevreviewribaudr proposed openstack/nova-specs master: Allow unshelve to a specific host  https://review.opendev.org/c/openstack/nova-specs/+/83150610:32
opendevreviewribaudr proposed openstack/nova master: Allow unshelve to a specific host  https://review.opendev.org/c/openstack/nova/+/83150710:33
Ugglasean-k-mooney, I have just pushed the unshelve to host specs ans api changes. I'll push the clients part asap.10:37
Ugglabauzas, fyi see msg just above.10:37
bauzasUggla: all good10:45
Ugglabauzas, Should I remove the link to the bug ? As the bug in not a lunchpad one but a bz one.10:47
bauzasUggla: oh yes10:47
bauzasUggla: don't push any internal BZ upstream :p10:48
bauzasnot all of us are working on the same company :p10:48
opendevreviewribaudr proposed openstack/nova master: Allow unshelve to a specific host  https://review.opendev.org/c/openstack/nova/+/83150710:49
Ugglabauzas, updated10:50
Ugglabauzas, should be clean now.10:50
bauzas++10:52
* bauzas goes preparing lunch for the kids10:53
Ugglabauzas, same for me. ;)10:57
plibeau4lyarwood: hello went you have time to review: https://review.opendev.org/c/openstack/nova/+/820531 thx11:19
gibiplibeau4: I will check. lyarwood is move away from openstack11:30
gibi*has moved11:30
gibiplibeau4: done. thank for fixing it11:36
opendevreviewChristian Rohmann proposed openstack/nova stable/ussuri: Fix the vGPU dynamic options race  https://review.opendev.org/c/openstack/nova/+/83152413:21
plibeau4gibi: thx for the info13:26
opendevreviewMerged openstack/nova master: Nova resize don't extend disk in one specific case  https://review.opendev.org/c/openstack/nova/+/82053113:36
gmannbauzas: gibi melwitt actually grenade skip job does not run any extra test than tempest tempest-integrated-compute so if we change any policy default in backward incompatible way then it will be catch by tempest-integrated-compute 14:40
gmannbauzas: gibi melwitt and nova-grenade-multinode is another grenade job we run on policy change. 14:42
*** dasm|off is now known as dasm|rover14:46
gmannone important thing is our deprecation policy period change as per new release model. we will have 1 years deprecation period so may be running grenade skip job can be helpful 14:55
bauzasgmann: oh ok, interesting thoughts15:09
gmannbauzas: gibi melwitt I think we should run on policy change keeping deprecation thing in mind15:11
gmanndansmith: ^^, you want to update that or i can do15:11
* bauzas reads carefully https://review.opendev.org/c/openstack/governance/+/828777/4/resolutions/20220210-release-cadence-adjustment.rst15:11
bauzasgmann: I haven't seen any official outcome of the voted resolution by email15:12
bauzasgmann: does the TC think about providing it ?15:12
bauzasnot sure all the projects have seen it15:12
dansmithgmann: change to *policies_irrelevant?15:13
gmannbauzas: yes, tha is plan as next step.15:13
gmanndansmith: yeah'15:13
dansmithack, I will, I waffled over that when I first wrote it15:13
bauzasgmann: OK thanks15:14
bauzasgmann: so, A will be the first 'tick' release, right?15:14
dansmithbauzas: working on that job, I hit the now-known bug where we broke FFUs, which is why I added that workaround15:14
* bauzas loves the tick/tock names: p15:14
dansmiththis will help catch things that break FFU as well, so pretty helpful for us downstream, IMHO15:14
bauzas:p15:14
bauzasI see15:15
dansmithbauzas: A will be the first tick, yoga->A is our opportunity to get it right15:15
bauzasand then zed ?15:15
dansmithzed is tock15:16
bauzasOK15:16
bauzasok, so yoga is 'tick', zed is 'tock' so we need to verify yoga > A 15:16
bauzasOK, understood15:16
dansmithyeah15:16
gmannyeah15:16
bauzasand if we want to deprecate something, we need to wait for zed15:17
dansmithyoga->Z is normal grenade job, and then when we start A, skip-level starts validating that we *keep* not breaking things from Y->A15:17
bauzasgot it15:17
dansmithbauzas: you can deprecate something any time you want, you just can't remove support for something in A that was supported in Y (unless they had homework to do in Y or something)15:18
bauzasI see15:18
bauzasso, we need to remove some stuff at the next 'tock' release 15:18
bauzassay we deprecate something in Z, we need to remove it in B15:19
bauzasif we deprecate something in A, we can remove it in B15:19
bauzasbut if we deprecate in B, we need to wait until D15:19
dansmithit depends on what it is and what happens to the users15:19
bauzasright?15:19
dansmithgive me an example and we should talk through it15:20
bauzasgood question15:20
bauzasabout policies, for example15:20
bauzasthe default is continuing to use the legacy15:20
dansmithwell, not sure that's a good one because I'm not sure we've ever actually had a switch like this15:21
bauzaswe were saying to start using the new policy scope/roles by default on Zed, right?15:21
dansmithbut,15:21
gmannI think we said deprecate and remove the things in tick release only not in tock15:21
dansmithif it's supported in A, then it needs to be support-able in C, but if it was deprecated in A, C can remove support for it if there's a reno that says "don't upgrade to C until you've done your work in A to remove dependence on deprecated policies"15:22
bauzasI see15:22
dansmiththe reason not to deprecate and remove things in a tock is because the reno will live in that tock, which people shouldn't have to look at in this scheme15:23
dansmithbut you definitely can't have, say, a required data migration in B that does work that wasn't done in A before they land at A15:23
dansmither, land at C15:23
dansmithit's really just the same rules we've always had, but only applied to tick releases15:23
dansmithif you consider tock equivalent to say m2 then it's the same procedure15:24
gmannbauzas: and for policy, plan is z - make enforce_scop=True by defaul but keep legacy policy (operator can disable the scope to keep it working) AA - remove the legacy policy15:24
bauzasdansmith: yeah, that's what I understood15:27
bauzaswe can only remove by a tick release15:27
bauzasand only if it was not supported by the previous tick release15:28
bauzasgot it?15:28
bauzasbut yeah gotcha, we take a tock release as an intermediate milestone15:28
dansmithI think it's more fine-grained and nuanced than that, but yes, that's a fine simple approximation15:28
bauzasOK15:31
bauzasthanks for explaining15:31
Ugglabauzas, did I understand well that the µapi version will not change in Yoga ? (remains 2.90)15:35
bauzasUggla: correct15:36
bauzaswe haven't merged any API change adding a new microversion15:36
bauzaswe had two of them be open in Yoga, none were merged15:37
bauzasso, for the moment, 2.92 is the next microversion15:37
bauzaswhops15:37
bauzas2.91 15:37
bauzasfucking fingers15:37
*** ykarel is now known as ykarel|away15:40
dansmithwow, no microversions in yoga?15:40
dansmiththat's both maybe a little scary and kinda amazing15:40
Ugglabauzas, cool so maybe I will not have to change it in my patch. \o/15:40
bauzasdansmith: we only had two open changes for it15:41
bauzasdansmith: one for tenant > project usage15:41
bauzasthe other one for a /servers new UUID parameter 15:42
bauzas(for booting to a specific hypervisor instead of using a very bad AZ param)15:43
dansmithbauzas: and the volume rebuild15:43
bauzasah right15:43
opendevreviewribaudr proposed openstack/nova master: Allow unshelve to a specific host  https://review.opendev.org/c/openstack/nova/+/83150716:12
melwittgmann: I understand there are no additional tempest test running on skip level job but nova-grenade-multinode will only be testing that policy change doesn't break N -> N+1 but only the skip level job will test N -> N+2. maybe I am missing something?16:22
melwittnvm just saw your later comment on the review16:25
dansmithoh sorry,16:26
dansmithI just realized my git-review failed to merge with master16:26
opendevreviewDan Smith proposed openstack/nova master: Add grenade-skip-level irrelevant-files config  https://review.opendev.org/c/openstack/nova/+/83122916:27
dansmiththar we go ^16:27
gmannmelwitt: yeah16:28
gmanndansmith: thanks 16:29
opendevreviewBalazs Gibizer proposed openstack/nova master: Record SRIOV PF MAC in the binding profile  https://review.opendev.org/c/openstack/nova/+/82924817:22
opendevreviewribaudr proposed openstack/nova master: Allow unshelve to a specific host  https://review.opendev.org/c/openstack/nova/+/83150717:42
ade_lee_sean-k-mooney, dansmith - hey - could you guys take a look at some jobs -- https://review.opendev.org/c/openstack/nova/+/82789519:44
ade_lee_sean-k-mooney, dansmith trying to figure out why the centos/fips jobs are failing -- this seems to be the same problem in other jobs too.19:45
ade_lee_sean-k-mooney, dansmith eharney looked and in tempest.api.compute.servers.test_server_rescue.ServerStableDeviceRescueTest.test_stable_device_rescue_disk_virtio_with_volume_attached    claims that the volume doesn't detach but if you look at the cinder and nova logs, it seems to be doing all the right things..19:46
ade_lee_(for instance)19:46
sean-k-mooneythat could be due to libvirt19:54
sean-k-mooneyis this happening on centos 9 stream19:54
sean-k-mooneyif its only centos  8 stream we shoudl proably ignore it19:55
sean-k-mooneyya the fips job is still centos 819:55
sean-k-mooneyso there are issues with q35 and device detach 19:55
sean-k-mooneydoes the fips job use the q35 manchien type?19:55
ade_lee_sean-k-mooney, q35?19:56
ade_lee_sean-k-mooney, let me retry it with centos-9 stream -- we want to move in that direction in any case19:57
clarkbsean-k-mooney: ade_lee_  I think the default was updated to q35 beacuse the previous default in devstack wouldn't boot centos-919:58
opendevreviewMerged openstack/nova stable/victoria: [rt] Apply migration context for incoming migrations  https://review.opendev.org/c/openstack/nova/+/82055919:59
sean-k-mooneyclarkb: that should not be done globally20:03
sean-k-mooneythat will break our testing expectations20:03
sean-k-mooneywe expect q35 to only be enabled in nova next currently20:03
clarkbah maybe we didn't jump that far ahead. We definitely had to move the machine type ahead to boot centos 920:04
sean-k-mooneyclarkb: you should not have too20:04
sean-k-mooneycentos 9 shoudl boot fine with pc20:04
sean-k-mooneyclarkb: do you have any link to that change20:05
clarkbah we bumped the cpu model not the chipset20:05
sean-k-mooneyah right20:05
clarkbe06d954229fc4fca827105f5bb0809a19075d59020:05
sean-k-mooneyto nehelm20:05
clarkbyes20:05
sean-k-mooneyya that is differnt20:06
sean-k-mooneythat is fien20:06
clarkbQ35 is older than nehalem though20:06
clarkbBut I guess those things don't move in lockstep when it comes to virt20:06
sean-k-mooneyq35 is basicaly the motherboard20:06
sean-k-mooneyrhather then cpu20:07
sean-k-mooneybut ya they are independent20:07
clarkbright but the era it comes from is pre nehalem20:07
sean-k-mooneyya20:07
clarkbnehalem was ~2021 and q35 was ~200720:07
clarkber 201220:07
clarkbtoo much typing 2021 last year20:07
sean-k-mooney:)20:07
ade_lee_sean-k-mooney, trying centos-9  -- lets see how that goes  .. https://review.opendev.org/c/openstack/tempest/+/831607/21:33
melwittgmann: just a heads up that the following devstack and tempest changes are dependencies for enabling unified limits test coverage in nova-next https://review.opendev.org/q/topic:bp/unified-limits-nova+AND+is:open+AND+(project:openstack/devstack+OR+project:openstack/tempest)22:37
*** dasm|rover is now known as dasm|off22:43
gmannmelwitt: ack, I will review tomorrow 23:50
melwittthanks gmann 23:53

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!