| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-03-08 | |||
| 17:08:07 | sean-k-mooney | since we key the fucntionality in old microverions | |
| 17:08:44 | bauzas | sean-k-mooney: IIUC, zed would be tock release | |
| 17:09:06 | sean-k-mooney | yes so we cant actully remvoe it until A | |
| 17:09:18 | bauzas | no | |
| 17:09:28 | bauzas | that's not what I understood | |
| 17:09:28 | sean-k-mooney | if we deprecate in yoga or zed we cant remove it until the next tick | |
| 17:09:34 | bauzas | given yoga was a tick release | |
| 17:09:48 | dansmith | to be clear, neither are tick or tock | |
| 17:09:49 | bauzas | we can't remove in the next tick release | |
| 17:10:31 | dansmith | tick-tock starts at A.. but thinking about this in terms of tick-tock is good exercise for sure | |
| 17:10:35 | bauzas | dansmith: damn, you should write a book "New OpenStack release cadence for Dummies" | |
| 17:10:56 | sean-k-mooney | dansmith: the patch mentioned treatign yoga to A as a dry run | |
| 17:10:57 | dansmith | bauzas: just consider tock as a milestone release | |
| 17:11:09 | bauzas | dansmith: that's what I understood | |
| 17:11:22 | dansmith | sean-k-mooney: yep, that's why I say going through the exercise is good, but it's not in force yet, is all I'm saying | |
| 17:11:22 | bauzas | dansmith: so removing an API deprecated in zed would be C, right? | |
| 17:11:37 | bauzas | it would be harsh if we would remove in A | |
| 17:11:56 | dansmith | bauzas: yes, but if you really deprecate it in zed, you would need to make sure that A *also* has it in the renos because people not deploying tock releases won't read those renos | |
| 17:12:02 | sean-k-mooney | "Y->A should be a "dress rehearsal" where we have the jobs enabled to help smoke out any issues, but where hard guarantees are not yet made." | |
| 17:12:36 | bauzas | dansmith: that's what I understood again | |
| 17:12:43 | sean-k-mooney | in anycase we woudl not remove this till A beacuew we likely wont deprecate in y at this point so the deprecation will be in zed | |
| 17:12:51 | bauzas | I'm assuming our relnotes won't be that read for Zed | |
| 17:12:56 | dansmith | bauzas: btw, doc fro the p-t-g: https://review.opendev.org/c/openstack/project-team-guide/+/832126/1/doc/source/deprecation.rst | |
| 17:13:16 | sean-k-mooney | bauzas: why i think that is not something we should assume | |
| 17:13:32 | bauzas | that reminds me to add an item to the nova etherpad about the cadence | |
| 17:13:39 | sean-k-mooney | im expecting that each tick will have the deperaction fomr the previous tick and tock | |
| 17:14:28 | bauzas | fortunately, we only have tick and tock releases and not Huey, Dewey and Louie releases | |
| 17:14:53 | sean-k-mooney | if we deprecate someitng in a tock are you sayign we need to keep it for a tick, tock and then we can remove in the second tick | |
| 17:15:39 | bauzas | sean-k-mooney: the new release cadence implies that tock releases are intermediate | |
| 17:15:43 | gmann | sean-k-mooney: issue in that is notification, if anyone not monitoring tock release as they can upgrade tick->tick | |
| 17:15:52 | dansmith | yes, because you haven't deprecated it in a release that those people are running | |
| 17:15:54 | gmann | so they miss the deprecation in tock | |
| 17:15:55 | dansmith | right | |
| 17:15:56 | bauzas | sean-k-mooney: there is no benefit into deprecating anything in a tock release | |
| 17:16:11 | dansmith | bauzas: pretty much that, yeah | |
| 17:16:18 | sean-k-mooney | hum ok so that basically means that we only deprecate in ticks | |
| 17:16:30 | bauzas | dansmith: again, are we assuming zed like a tock release unofficially, then ? | |
| 17:16:31 | sean-k-mooney | and then remove in the next tick at the earliest | |
| 17:16:41 | bauzas | sean-k-mooney: you're correct | |
| 17:17:08 | bauzas | to quote dansmith, tock releases are tick-4 releases | |
| 17:17:14 | dansmith | bauzas: unofficially yeah, yoga is "practice tick", zed is "practice tock" and then we commit on AA | |
| 17:17:39 | bauzas | tick-4 s/releases/milestones my bad | |
| 17:17:48 | sean-k-mooney | if we deprecated in a tick is there any reason not to remove in the next tock | |
| 17:17:51 | bauzas | dansmith: ack, pretty clear now | |
| 17:18:00 | sean-k-mooney | since the notice would have been given | |
| 17:18:12 | sean-k-mooney | and for tick to tick upgrades ther is no delta | |
| 17:18:18 | bauzas | sean-k-mooney: no, you need to wait the next tick to remove | |
| 17:18:34 | sean-k-mooney | why if its tick to tick you cant tell the difference | |
| 17:18:35 | bauzas | sean-k-mooney: again, thinking in terms of milestones helps | |
| 17:18:35 | dansmith | sean-k-mooney: well, for people deploying all of them, you'd normally give two cycles yeah? depending on what it is | |
| 17:19:01 | sean-k-mooney | well we give at least one but up to two but sure | |
| 17:19:05 | bauzas | fun, timeout on the PTG schedule agenda https://ethercalc.openstack.org/7yxdas7suqnd | |
| 17:19:08 | bauzas | is it me ? | |
| 17:19:13 | sean-k-mooney | *not up to but offten two | |
| 17:19:31 | bauzas | sean-k-mooney: that's why I'm adding the release cadence to the PTG agenda | |
| 17:19:53 | bauzas | sean-k-mooney: given zed would be a dryrun tock release, let's practice and avoid deprecations in it | |
| 17:19:59 | gmann | bauzas: ethercal seems down for me too at least. | |
| 17:20:07 | sean-k-mooney | basiically if feels asymetic to me | |
| 17:20:15 | bauzas | gmann: ok, I'll try to jab diablo_rojo | |
| 17:20:22 | sean-k-mooney | deprecations in ticks vs tocks have diffeent notice periods | |
| 17:20:36 | gmann | bauzas: sean-k-mooney and we can plan something in TC+PTL sessions too where dansmith can explain/answer the question. | |
| 17:20:40 | rribaud__ | bauzas, same for me https://ethercalc.openstack.org/7yxdas7suqnd seems not answering. | |
| 17:20:46 | sean-k-mooney | i could see jus extendign to at least 2 release working | |
| 17:21:40 | sean-k-mooney | e.g. depreacte in a tick (cant remove till next tick) deprecate in tock (cant remove until next tock) | |
| 17:21:58 | bauzas | gmann: sure, I think I got the memo but discussing the outcomes is a good idea | |
| 17:21:58 | sean-k-mooney | that way all deprecation have at least 2 cycles of notice | |
| 17:22:18 | sean-k-mooney | but it does not end up pilling up 2 cycles of removals into every tick | |
| 17:22:40 | bauzas | sean-k-mooney: take it as we won't do any removal or deprecation during a tock release | |
| 17:22:51 | sean-k-mooney | bauzas: i really dont like that idea | |
| 17:22:53 | bauzas | those are just skipped releases for ops by now | |
| 17:22:59 | dansmith | bauzas: right, that's the easiest thing to do | |
| 17:23:23 | dansmith | bauzas: for something that's really big, if we wanted two ticks of deprecation, removing in the following tock would be reasonable | |
| 17:23:39 | dansmith | maybe something like n-net or virt/xen where we wanted lots of notice | |
| 17:23:44 | bauzas | sean-k-mooney: we have the TC+PTL session before our nova PTG sessions, it's good you gonna attend those | |
| 17:23:58 | sean-k-mooney | i proably will | |
| 17:24:13 | bauzas | dansmith: I see | |
| 17:24:20 | sean-k-mooney | but we will see we need to do this consitently across openstack | |
| 17:24:28 | bauzas | dansmith: deprecate in A, B, C and drop in D | |
| 17:24:46 | bauzas | which means operators would notice it in E | |
| 17:24:50 | dansmith | bauzas: for something really major yeah.. just an example | |
| 17:24:51 | sean-k-mooney | for big things perhaps | |
| 17:25:01 | sean-k-mooney | but in general that feels pretty heavy weight | |
| 17:25:16 | bauzas | dansmith: oh, yeah, got it | |
| 17:25:22 | dansmith | sean-k-mooney: well, I think it's in line with how we've handled things like virt/xen | |
| 17:25:37 | dansmith | and n-net certainly had looots of time between effective death and removal :) | |
| 17:25:53 | bauzas | yeah I see | |
| 17:26:11 | sean-k-mooney | right but that means things like the rpc proxy shoudl not be removed for 3-4 cycles | |
| 17:26:14 | bauzas | we can remove things in a tock release as ops would catch up on it on the next tick release | |
| 17:26:27 | sean-k-mooney | or reshapes which granted we have nver removed yet | |
| 17:26:31 | bauzas | sean-k-mooney: like the RPC compatibilities | |
| 17:26:39 | sean-k-mooney | its not just deprecation it affect | |
| 17:27:00 | bauzas | we can technically drop RPC compat on a tock release, it's just ops won't get it in effect until the next tick | |
| 17:27:21 | sean-k-mooney | so this feels abit like longer release cycles by stelth in a way that i am not sure is sustainable | |
| 17:27:54 | dansmith | sean-k-mooney: it is like that, and not by stealth | |
| 17:28:00 | dansmith | the whole point of this was to strike a balance | |
| 17:28:11 | sean-k-mooney | ya which this does not really do | |
| 17:28:14 | dansmith | the benefit here over longer cycles is that, deprecation aside, we can release *features* every cycle :) | |
| 17:28:33 | dansmith | and we can deliver code, fixes, changes to people more often than once a year | |
| 17:28:52 | bauzas | dansmith: but I guess we'd think of forward porting the relnotes to the next tick release ? | |
| 17:28:53 | sean-k-mooney | yes | |