Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-03-02
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 dansmith this will help catch things that break FFU as well, so pretty helpful for us downstream, IMHO
15:14:59 bauzas :p
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
15:28:52 dansmith I think it's more fine-grained and nuanced than that, but yes, that's a fine simple approximation
15:31:33 bauzas OK
15:31:38 bauzas thanks for explaining
15:35:12 Uggla bauzas, did I understand well that the µapi version will not change in Yoga ? (remains 2.90)
15:36:44 bauzas Uggla: correct
15:36:58 bauzas we haven't merged any API change adding a new microversion
15:37:13 bauzas we had two of them be open in Yoga, none were merged
15:37:31 bauzas so, for the moment, 2.92 is the next microversion
15:37:34 bauzas whops
15:37:38 bauzas 2.91
15:37:43 bauzas fucking fingers
15:40:17 dansmith wow, no microversions in yoga?
15:40:24 dansmith that's both maybe a little scary and kinda amazing
15:40:50 Uggla bauzas, cool so maybe I will not have to change it in my patch. \o/
15:41:15 bauzas dansmith: we only had two open changes for it
15:41:30 bauzas dansmith: one for tenant > project usage
15:42:30 bauzas the other one for a /servers new UUID parameter
15:43:12 bauzas (for booting to a specific hypervisor instead of using a very bad AZ param)
15:43:28 dansmith bauzas: and the volume rebuild
15:43:33 bauzas ah right
16:12:09 opendevreview ribaudr proposed openstack/nova master: Allow unshelve to a specific host https://review.opendev.org/c/openstack/nova/+/831507
16:22:59 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:25:47 melwitt nvm just saw your later comment on the review
16:26:00 dansmith oh sorry,
16:26:07 dansmith I just realized my git-review failed to merge with master
16:27:50 opendevreview Dan Smith proposed openstack/nova master: Add grenade-skip-level irrelevant-files config https://review.opendev.org/c/openstack/nova/+/831229
16:27:54 dansmith thar we go ^

Earlier   Later