| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-03-08 | |||
| 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 | |
| 17:32:35 | sean-k-mooney | i guess | |
| 17:32:51 | sean-k-mooney | i hate having to look in mulitple places | |
| 17:32:56 | gmann | we can add a line in the top or so that 'to know all change from tick1->tick2 read these tock releasenotes too' | |
| 17:32:57 | dansmith | just MHO, but I think we're already incredibly verbose on the renos | |
| 17:32:57 | sean-k-mooney | but you coudl do it either way | |
| 17:33:19 | sean-k-mooney | dansmith: i mean perhaps prelude and upgrades section maybe | |
| 17:33:40 | sean-k-mooney | i guess we will figure it out | |
| 17:33:47 | gmann | will there be any upgrade section in tock? i mean we want to avoid those like depreaction right | |
| 17:33:59 | dansmith | gmann: sometimes features bring upgrade items I think | |
| 17:34:00 | sean-k-mooney | gmann: there should be | |
| 17:34:17 | sean-k-mooney | gmann: i really dont thinik we shoudl try to avoid either in a tock | |
| 17:34:22 | gmann | ah new feature. got it | |
| 17:34:32 | sean-k-mooney | if we do it will slow down devleopment | |
| 17:34:54 | sean-k-mooney | gmann: addin a db migraition for a new feature woudl be an upgrade impact i coudl see in a tock | |
| 17:35:05 | dansmith | sean-k-mooney: remember this is a compromise, some things will have to change.. hopefully less with this than the alternative | |
| 17:35:09 | gmann | making release notes page too verbose and long make them hard to read good things. I think link to tock releease notes in tick releasenotes should be fine | |
| 17:35:21 | dansmith | gmann: agree | |
| 17:35:55 | sean-k-mooney | dansmith: right but if we cant do db changes in a tock or rpc change for example then tha tis not a compromise | |
| 17:36:20 | dansmith | sean-k-mooney: as noted, I think it's totally fine to *add* things to db and rpc in tock | |
| 17:38:48 | bauzas | yup | |
| 17:39:00 | bauzas | we can rpc bump things in a tock | |
| 17:39:12 | bauzas | if we have rpc compat of courser | |
| 17:39:25 | bauzas | we can add a db upgrade script too | |
| 17:40:06 | bauzas | we can even remove a rpc compat on a tock release if compat was there on the previous tick | |
| 17:40:22 | bauzas | rpc aliases will continue to exist | |
| 17:40:31 | bauzas | and microversions too | |
| 17:41:18 | bauzas | but somehow we need to settle a couple of rules we gonna write on our contrib docs | |
| 17:41:54 | bauzas | that's why I want us to agree on the impacts for nova so we can write it down | |
| 17:42:27 | gmann | bauzas: +1. | |
| 17:43:07 | gmann | bauzas: sean-k-mooney added it on TC+PTL slots, L27 - https://etherpad.opendev.org/p/tc-ptl-interaction-zed | |
| 17:45:07 | sean-k-mooney | gmann: thanks | |
| 17:45:44 | sean-k-mooney | bauzas: yes we have time to figure that out before AA | |
| 17:53:24 | sean-k-mooney | ok im hungery so im going to grab something to eat i might be on irc later but i will likely just work on some reviews for the evning | |
| 17:53:48 | opendevreview | Sylvain Bauza proposed openstack/nova master: Add the Yoga prelude section https://review.opendev.org/c/openstack/nova/+/832292 | |
| 17:54:07 | bauzas | gmann: dansmith: melwitt: sean-k-mooney: gibi: new revision for the Yoga prelude ^ | |