| gmann | bauzas: gibi easy one to avoid grenade-skip job running on doc/test patches https://review.opendev.org/c/openstack/nova/+/831229 | 00:34 |
|---|---|---|
| gmann | melwitt: sean-k-mooney ^^ if any one of you around | 00:34 |
| melwitt | gmann: 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 |
| melwitt | it also shows as merge conflict | 01:02 |
| gibi | gmann, melwitt: I agree with melwitt, I think we need to trigger on policy changes too | 06:48 |
| bauzas | gibi: gmann: melwitt: dansmith: me too | 07:47 |
| bauzas | easy change FTW | 07:47 |
| opendevreview | Merged openstack/nova stable/wallaby: Migrate RequestSpec.numa_topology to use pcpuset https://review.opendev.org/c/openstack/nova/+/827871 | 09:28 |
| opendevreview | ribaudr proposed openstack/nova-specs master: Allow unshelve to a specific host https://review.opendev.org/c/openstack/nova-specs/+/831506 | 10:32 |
| opendevreview | ribaudr proposed openstack/nova master: Allow unshelve to a specific host https://review.opendev.org/c/openstack/nova/+/831507 | 10:33 |
| Uggla | sean-k-mooney, I have just pushed the unshelve to host specs ans api changes. I'll push the clients part asap. | 10:37 |
| Uggla | bauzas, fyi see msg just above. | 10:37 |
| bauzas | Uggla: all good | 10:45 |
| Uggla | bauzas, Should I remove the link to the bug ? As the bug in not a lunchpad one but a bz one. | 10:47 |
| bauzas | Uggla: oh yes | 10:47 |
| bauzas | Uggla: don't push any internal BZ upstream :p | 10:48 |
| bauzas | not all of us are working on the same company :p | 10:48 |
| opendevreview | ribaudr proposed openstack/nova master: Allow unshelve to a specific host https://review.opendev.org/c/openstack/nova/+/831507 | 10:49 |
| Uggla | bauzas, updated | 10:50 |
| Uggla | bauzas, should be clean now. | 10:50 |
| bauzas | ++ | 10:52 |
| * bauzas goes preparing lunch for the kids | 10:53 | |
| Uggla | bauzas, same for me. ;) | 10:57 |
| plibeau4 | lyarwood: hello went you have time to review: https://review.opendev.org/c/openstack/nova/+/820531 thx | 11:19 |
| gibi | plibeau4: I will check. lyarwood is move away from openstack | 11:30 |
| gibi | *has moved | 11:30 |
| gibi | plibeau4: done. thank for fixing it | 11:36 |
| opendevreview | Christian Rohmann proposed openstack/nova stable/ussuri: Fix the vGPU dynamic options race https://review.opendev.org/c/openstack/nova/+/831524 | 13:21 |
| plibeau4 | gibi: thx for the info | 13:26 |
| opendevreview | Merged openstack/nova master: Nova resize don't extend disk in one specific case https://review.opendev.org/c/openstack/nova/+/820531 | 13:36 |
| gmann | bauzas: 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 |
| gmann | bauzas: gibi melwitt and nova-grenade-multinode is another grenade job we run on policy change. | 14:42 |
| *** dasm|off is now known as dasm|rover | 14:46 | |
| gmann | one 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 |
| bauzas | gmann: oh ok, interesting thoughts | 15:09 |
| gmann | bauzas: gibi melwitt I think we should run on policy change keeping deprecation thing in mind | 15:11 |
| gmann | dansmith: ^^, you want to update that or i can do | 15:11 |
| * bauzas reads carefully https://review.opendev.org/c/openstack/governance/+/828777/4/resolutions/20220210-release-cadence-adjustment.rst | 15:11 | |
| bauzas | gmann: I haven't seen any official outcome of the voted resolution by email | 15:12 |
| bauzas | gmann: does the TC think about providing it ? | 15:12 |
| bauzas | not sure all the projects have seen it | 15:12 |
| dansmith | gmann: change to *policies_irrelevant? | 15:13 |
| gmann | bauzas: yes, tha is plan as next step. | 15:13 |
| gmann | dansmith: yeah' | 15:13 |
| dansmith | ack, I will, I waffled over that when I first wrote it | 15:13 |
| bauzas | gmann: OK thanks | 15:14 |
| bauzas | gmann: so, A will be the first 'tick' release, right? | 15:14 |
| dansmith | bauzas: working on that job, I hit the now-known bug where we broke FFUs, which is why I added that workaround | 15:14 |
| * bauzas loves the tick/tock names: p | 15:14 | |
| dansmith | this will help catch things that break FFU as well, so pretty helpful for us downstream, IMHO | 15:14 |
| bauzas | :p | 15:14 |
| bauzas | I see | 15:15 |
| dansmith | bauzas: A will be the first tick, yoga->A is our opportunity to get it right | 15:15 |
| bauzas | and then zed ? | 15:15 |
| dansmith | zed is tock | 15:16 |
| bauzas | OK | 15:16 |
| bauzas | ok, so yoga is 'tick', zed is 'tock' so we need to verify yoga > A | 15:16 |
| bauzas | OK, understood | 15:16 |
| dansmith | yeah | 15:16 |
| gmann | yeah | 15:16 |
| bauzas | and if we want to deprecate something, we need to wait for zed | 15:17 |
| dansmith | yoga->Z is normal grenade job, and then when we start A, skip-level starts validating that we *keep* not breaking things from Y->A | 15:17 |
| bauzas | got it | 15:17 |
| dansmith | bauzas: 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 |
| bauzas | I see | 15:18 |
| bauzas | so, we need to remove some stuff at the next 'tock' release | 15:18 |
| bauzas | say we deprecate something in Z, we need to remove it in B | 15:19 |
| bauzas | if we deprecate something in A, we can remove it in B | 15:19 |
| bauzas | but if we deprecate in B, we need to wait until D | 15:19 |
| dansmith | it depends on what it is and what happens to the users | 15:19 |
| bauzas | right? | 15:19 |
| dansmith | give me an example and we should talk through it | 15:20 |
| bauzas | good question | 15:20 |
| bauzas | about policies, for example | 15:20 |
| bauzas | the default is continuing to use the legacy | 15:20 |
| dansmith | well, not sure that's a good one because I'm not sure we've ever actually had a switch like this | 15:21 |
| bauzas | we were saying to start using the new policy scope/roles by default on Zed, right? | 15:21 |
| dansmith | but, | 15:21 |
| gmann | I think we said deprecate and remove the things in tick release only not in tock | 15:21 |
| dansmith | if 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 |
| bauzas | I see | 15:22 |
| dansmith | the 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 scheme | 15:23 |
| dansmith | but 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 A | 15:23 |
| dansmith | er, land at C | 15:23 |
| dansmith | it's really just the same rules we've always had, but only applied to tick releases | 15:23 |
| dansmith | if you consider tock equivalent to say m2 then it's the same procedure | 15:24 |
| gmann | bauzas: 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 policy | 15:24 |
| bauzas | dansmith: yeah, that's what I understood | 15:27 |
| bauzas | we can only remove by a tick release | 15:27 |
| bauzas | and only if it was not supported by the previous tick release | 15:28 |
| bauzas | got it? | 15:28 |
| bauzas | but yeah gotcha, we take a tock release as an intermediate milestone | 15:28 |
| dansmith | I think it's more fine-grained and nuanced than that, but yes, that's a fine simple approximation | 15:28 |
| bauzas | OK | 15:31 |
| bauzas | thanks for explaining | 15:31 |
| Uggla | bauzas, did I understand well that the µapi version will not change in Yoga ? (remains 2.90) | 15:35 |
| bauzas | Uggla: correct | 15:36 |
| bauzas | we haven't merged any API change adding a new microversion | 15:36 |
| bauzas | we had two of them be open in Yoga, none were merged | 15:37 |
| bauzas | so, for the moment, 2.92 is the next microversion | 15:37 |
| bauzas | whops | 15:37 |
| bauzas | 2.91 | 15:37 |
| bauzas | fucking fingers | 15:37 |
| *** ykarel is now known as ykarel|away | 15:40 | |
| dansmith | wow, no microversions in yoga? | 15:40 |
| dansmith | that's both maybe a little scary and kinda amazing | 15:40 |
| Uggla | bauzas, cool so maybe I will not have to change it in my patch. \o/ | 15:40 |
| bauzas | dansmith: we only had two open changes for it | 15:41 |
| bauzas | dansmith: one for tenant > project usage | 15:41 |
| bauzas | the 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 |
| dansmith | bauzas: and the volume rebuild | 15:43 |
| bauzas | ah right | 15:43 |
| opendevreview | ribaudr proposed openstack/nova master: Allow unshelve to a specific host https://review.opendev.org/c/openstack/nova/+/831507 | 16:12 |
| melwitt | gmann: 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 |
| melwitt | nvm just saw your later comment on the review | 16:25 |
| dansmith | oh sorry, | 16:26 |
| dansmith | I just realized my git-review failed to merge with master | 16:26 |
| opendevreview | Dan Smith proposed openstack/nova master: Add grenade-skip-level irrelevant-files config https://review.opendev.org/c/openstack/nova/+/831229 | 16:27 |
| dansmith | thar we go ^ | 16:27 |
| gmann | melwitt: yeah | 16:28 |
| gmann | dansmith: thanks | 16:29 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Record SRIOV PF MAC in the binding profile https://review.opendev.org/c/openstack/nova/+/829248 | 17:22 |
| opendevreview | ribaudr proposed openstack/nova master: Allow unshelve to a specific host https://review.opendev.org/c/openstack/nova/+/831507 | 17:42 |
| ade_lee_ | sean-k-mooney, dansmith - hey - could you guys take a look at some jobs -- https://review.opendev.org/c/openstack/nova/+/827895 | 19: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-mooney | that could be due to libvirt | 19:54 |
| sean-k-mooney | is this happening on centos 9 stream | 19:54 |
| sean-k-mooney | if its only centos 8 stream we shoudl proably ignore it | 19:55 |
| sean-k-mooney | ya the fips job is still centos 8 | 19:55 |
| sean-k-mooney | so there are issues with q35 and device detach | 19:55 |
| sean-k-mooney | does 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 case | 19:57 |
| clarkb | sean-k-mooney: ade_lee_ I think the default was updated to q35 beacuse the previous default in devstack wouldn't boot centos-9 | 19:58 |
| opendevreview | Merged openstack/nova stable/victoria: [rt] Apply migration context for incoming migrations https://review.opendev.org/c/openstack/nova/+/820559 | 19:59 |
| sean-k-mooney | clarkb: that should not be done globally | 20:03 |
| sean-k-mooney | that will break our testing expectations | 20:03 |
| sean-k-mooney | we expect q35 to only be enabled in nova next currently | 20:03 |
| clarkb | ah maybe we didn't jump that far ahead. We definitely had to move the machine type ahead to boot centos 9 | 20:04 |
| sean-k-mooney | clarkb: you should not have too | 20:04 |
| sean-k-mooney | centos 9 shoudl boot fine with pc | 20:04 |
| sean-k-mooney | clarkb: do you have any link to that change | 20:05 |
| clarkb | ah we bumped the cpu model not the chipset | 20:05 |
| sean-k-mooney | ah right | 20:05 |
| clarkb | e06d954229fc4fca827105f5bb0809a19075d590 | 20:05 |
| sean-k-mooney | to nehelm | 20:05 |
| clarkb | yes | 20:05 |
| sean-k-mooney | ya that is differnt | 20:06 |
| sean-k-mooney | that is fien | 20:06 |
| clarkb | Q35 is older than nehalem though | 20:06 |
| clarkb | But I guess those things don't move in lockstep when it comes to virt | 20:06 |
| sean-k-mooney | q35 is basicaly the motherboard | 20:06 |
| sean-k-mooney | rhather then cpu | 20:07 |
| sean-k-mooney | but ya they are independent | 20:07 |
| clarkb | right but the era it comes from is pre nehalem | 20:07 |
| sean-k-mooney | ya | 20:07 |
| clarkb | nehalem was ~2021 and q35 was ~2007 | 20:07 |
| clarkb | er 2012 | 20:07 |
| clarkb | too much typing 2021 last year | 20: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 |
| melwitt | gmann: 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|off | 22:43 | |
| gmann | melwitt: ack, I will review tomorrow | 23:50 |
| melwitt | thanks gmann | 23:53 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!