| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-03-08 | |||
| 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 | |
| 17:29:06 | dansmith | bauzas: I'd say just prelude items | |
| 17:29:11 | bauzas | dansmith: a good reno tooling opportunity | |
| 17:29:18 | dansmith | bauzas: i.e. anything major enough to make it into prelude in a tock is candidate for tick | |
| 17:29:20 | sean-k-mooney | but we are addign teh cost of maintianing things we want to deprecate and remove for 2-3 release instead of just one to two | |
| 17:29:41 | dansmith | sean-k-mooney: yep, this is not free for sure.. but it's benefit to people, which has a cost | |
| 17:29:41 | gmann | which is what we do in most of the case currently | |
| 17:29:59 | sean-k-mooney | like with the xen removeal we woudl have deprecated it in one relase and had to wait 2 release to remove it after noone stepped up to maintian it | |
| 17:30:00 | bauzas | dansmith: this sounds reasonable, I need to see how to split the prelude in multiple patches | |
| 17:30:23 | bauzas | dansmith: so we could forward port the big prelude patch to the next release | |
| 17:30:43 | dansmith | bauzas: or just manually copy the items.. I don't think you need to get too sophisticated :) | |
| 17:30:57 | bauzas | are you asking copy/paste ? man ! | |
| 17:31:00 | sean-k-mooney | bauzas: actuly i think we want reno to know what tick and tock releases are | |
| 17:31:18 | sean-k-mooney | and include the release notes form the previous tock in the tick | |
| 17:31:19 | dansmith | sean-k-mooney: personally, I wouldn't do that | |
| 17:31:24 | sean-k-mooney | no | |
| 17:31:28 | dansmith | I think that's a mistake | |
| 17:31:32 | sean-k-mooney | why ? | |
| 17:31:50 | dansmith | don't make them read double the release notes, as compiled by a computer | |
| 17:32:01 | dansmith | bring forward the important bits (i.e. likely the content of the prelude) | |
| 17:32:06 | sean-k-mooney | an operator goign form tick 1 to tick 2 need to know everythign that happend in tock 1 right | |
| 17:32:20 | dansmith | they can read the intermediate release notes if they want, but don't just concat them | |