| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-03-01 | |||
| 18:10:57 | dansmith | the reason to break these things apart is to make sure each step works, because in reality, not all the services get upgraded at the same time in a real deployment, | |
| 18:11:36 | dansmith | so doing the steps like this help ensure that we're not just shifting the state of the world atomically, which is how we discovered that the behavior of rebuild had changed, when we separated the api patch from the implementation | |
| 18:12:13 | dansmith | it's not a "hack" to add a parameter that is the equivalent of what we have today as we step through those changes, it's just keeping things compatible | |
| 18:13:54 | whoami-rajat | I understand why we are doing it like this but we already have rpc versions to check and maintain that compatibility (although this provides more assurance) | |
| 18:14:24 | whoami-rajat | but again, in a real deployment as well, if the compute is new and conductor is old, we will see the same failure in the logs as these tests | |
| 18:14:30 | dansmith | but we had versions in the initial unified patch, which weren't properly honoring the old behavior :) | |
| 18:14:59 | dansmith | whoami-rajat: just FYI, conductor always has to be upgraded before compute, it's in our upgrade process | |
| 18:15:08 | dansmith | api and conductor together, compute after | |
| 18:18:10 | whoami-rajat | we weren't passing the reimage_boot_volume parameter down to the compute in the initial patch so there weren't the RPC bumps but i get what you're saying, we wouldn't have discovered the issue if it wasn't for the split | |
| 18:18:25 | whoami-rajat | maybe it's just new for me to split the different services code apart | |
| 18:18:32 | whoami-rajat | sorry for all the fuzz created :) | |
| 18:18:46 | dansmith | s'ok, let's just get it right :) | |
| 18:19:03 | whoami-rajat | ack, on it | |
| 18:19:21 | opendevreview | Merged openstack/nova master: Move file system freeze after end of mirroring https://review.opendev.org/c/openstack/nova/+/803713 | |
| 18:40:09 | chateaulav | gibi: im guessing for https://review.opendev.org/c/openstack/nova/+/828372 the -2 V is just an occasional hiccup with gate jobs | |
| 18:41:09 | elodilles | dansmith: when you have some time, can you please use your stable core power on this one-liner patch? :) https://review.opendev.org/c/openstack/nova/+/830656/ | |
| 18:41:21 | gibi | chateaulav: yepp, feel free to recheck | |
| 18:42:01 | chateaulav | cool | |
| 18:45:03 | dansmith | elodilles: done | |
| 18:47:58 | opendevreview | Rajat Dhasmana proposed openstack/nova master: Add support for volume backed server rebuild https://review.opendev.org/c/openstack/nova/+/820368 | |
| 18:47:59 | opendevreview | Rajat Dhasmana proposed openstack/nova master: Add API support for rebuilding BFV instances https://review.opendev.org/c/openstack/nova/+/830883 | |
| 18:47:59 | opendevreview | Rajat Dhasmana proposed openstack/nova master: Add conductor RPC interface for rebuild https://review.opendev.org/c/openstack/nova/+/831219 | |
| 18:48:26 | whoami-rajat | dansmith, instead of one, it was 3 line change but tests are passing now ^ | |
| 18:48:38 | dansmith | cool | |
| 18:58:14 | elodilles | dansmith: thanks! \o/ | |
| 20:28:45 | opendevreview | Merged openstack/nova stable/wallaby: skip test_tagged_attachment in nova-next https://review.opendev.org/c/openstack/nova/+/830656 | |
| 22:05:22 | opendevreview | Merged openstack/nova master: zuul-job for Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/nova/+/828372 | |
| #openstack-nova - 2022-03-02 | |||
| 00:34:10 | 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:29 | gmann | melwitt: sean-k-mooney ^^ if any one of you around | |
| 00:53:38 | 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? | |
| 01:02:05 | melwitt | it also shows as merge conflict | |
| 06:48:21 | gibi | gmann, melwitt: I agree with melwitt, I think we need to trigger on policy changes too | |
| 07:47:46 | bauzas | gibi: gmann: melwitt: dansmith: me too | |
| 07:47:55 | bauzas | easy change FTW | |
| 09:28:10 | opendevreview | Merged openstack/nova stable/wallaby: Migrate RequestSpec.numa_topology to use pcpuset https://review.opendev.org/c/openstack/nova/+/827871 | |
| 10:32:18 | opendevreview | ribaudr proposed openstack/nova-specs master: Allow unshelve to a specific host https://review.opendev.org/c/openstack/nova-specs/+/831506 | |
| 10:33:05 | opendevreview | ribaudr proposed openstack/nova master: Allow unshelve to a specific host https://review.opendev.org/c/openstack/nova/+/831507 | |
| 10:37:26 | 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:54 | Uggla | bauzas, fyi see msg just above. | |
| 10:45:27 | bauzas | Uggla: all good | |
| 10:47:06 | Uggla | bauzas, Should I remove the link to the bug ? As the bug in not a lunchpad one but a bz one. | |
| 10:47:44 | bauzas | Uggla: oh yes | |
| 10:48:02 | bauzas | Uggla: don't push any internal BZ upstream :p | |
| 10:48:12 | bauzas | not all of us are working on the same company :p | |
| 10:49:24 | opendevreview | ribaudr proposed openstack/nova master: Allow unshelve to a specific host https://review.opendev.org/c/openstack/nova/+/831507 | |
| 10:50:32 | Uggla | bauzas, updated | |
| 10:50:52 | Uggla | bauzas, should be clean now. | |
| 10:52:45 | bauzas | ++ | |
| 10:57:24 | Uggla | bauzas, same for me. ;) | |
| 11:19:47 | plibeau4 | lyarwood: hello went you have time to review: https://review.opendev.org/c/openstack/nova/+/820531 thx | |
| 11:30:13 | gibi | plibeau4: I will check. lyarwood is move away from openstack | |
| 11:30:21 | gibi | *has moved | |
| 11:36:10 | gibi | plibeau4: done. thank for fixing it | |
| 13:21:24 | opendevreview | Christian Rohmann proposed openstack/nova stable/ussuri: Fix the vGPU dynamic options race https://review.opendev.org/c/openstack/nova/+/831524 | |
| 13:26:09 | plibeau4 | gibi: thx for the info | |
| 13:36:19 | opendevreview | Merged openstack/nova master: Nova resize don't extend disk in one specific case https://review.opendev.org/c/openstack/nova/+/820531 | |
| 14:40:05 | 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:42:10 | gmann | bauzas: gibi melwitt and nova-grenade-multinode is another grenade job we run on policy change. | |
| 14:55:57 | 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 | |
| 15:09:56 | bauzas | gmann: oh ok, interesting thoughts | |
| 15:11:14 | gmann | bauzas: gibi melwitt I think we should run on policy change keeping deprecation thing in mind | |
| 15:11:33 | gmann | dansmith: ^^, you want to update that or i can do | |
| 15:12:09 | bauzas | gmann: I haven't seen any official outcome of the voted resolution by email | |
| 15:12:18 | bauzas | gmann: does the TC think about providing it ? | |
| 15:12:37 | bauzas | not sure all the projects have seen it | |
| 15:13:23 | dansmith | gmann: change to *policies_irrelevant? | |
| 15:13:33 | gmann | bauzas: yes, tha is plan as next step. | |
| 15:13:38 | gmann | dansmith: yeah' | |
| 15:13:58 | dansmith | ack, I will, I waffled over that when I first wrote it | |
| 15:14:22 | bauzas | gmann: OK thanks | |
| 15:14:34 | bauzas | gmann: so, A will be the first 'tick' release, right? | |
| 15:14:38 | 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:59 | bauzas | :p | |
| 15:14:59 | dansmith | this will help catch things that break FFU as well, so pretty helpful for us downstream, IMHO | |
| 15:15:26 | bauzas | I see | |
| 15:15:30 | dansmith | bauzas: A will be the first tick, yoga->A is our opportunity to get it right | |
| 15:15:54 | bauzas | and then zed ? | |
| 15:16:03 | dansmith | zed is tock | |
| 15:16:05 | bauzas | OK | |
| 15:16:43 | bauzas | ok, so yoga is 'tick', zed is 'tock' so we need to verify yoga > A | |
| 15:16:45 | bauzas | OK, understood | |
| 15:16:50 | dansmith | yeah | |
| 15:16:51 | gmann | yeah | |
| 15:17:13 | bauzas | and if we want to deprecate something, we need to wait for zed | |
| 15:17:19 | 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:45 | bauzas | got it | |
| 15:18:04 | 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:23 | bauzas | I see | |
| 15:18:41 | bauzas | so, we need to remove some stuff at the next 'tock' release | |
| 15:19:19 | bauzas | say we deprecate something in Z, we need to remove it in B | |
| 15:19:38 | bauzas | if we deprecate something in A, we can remove it in B | |
| 15:19:48 | bauzas | but if we deprecate in B, we need to wait until D | |
| 15:19:49 | dansmith | it depends on what it is and what happens to the users | |
| 15:19:50 | bauzas | right? | |
| 15:20:03 | dansmith | give me an example and we should talk through it | |
| 15:20:14 | bauzas | good question | |
| 15:20:21 | bauzas | about policies, for example | |
| 15:20:45 | bauzas | the default is continuing to use the legacy | |
| 15:21:39 | 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:40 | bauzas | we were saying to start using the new policy scope/roles by default on Zed, right? | |