| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-03-01 | |||
| 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? | |
| 15:21:41 | dansmith | but, | |
| 15:21:55 | gmann | I think we said deprecate and remove the things in tick release only not in tock | |
| 15:22:28 | 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:59 | bauzas | I see | |
| 15:23:00 | 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:20 | 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:23 | dansmith | er, land at C | |
| 15:23:53 | dansmith | it's really just the same rules we've always had, but only applied to tick releases | |
| 15:24:06 | dansmith | if you consider tock equivalent to say m2 then it's the same procedure | |
| 15:24:11 | 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:27:29 | bauzas | dansmith: yeah, that's what I understood | |
| 15:27:41 | bauzas | we can only remove by a tick release | |
| 15:28:06 | bauzas | and only if it was not supported by the previous tick release | |
| 15:28:17 | bauzas | got it? | |
| 15:28:44 | bauzas | but yeah gotcha, we take a tock release as an intermediate milestone | |