| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-18 | |||
| 16:42:34 | sean-k-mooney | we can proably fix that | |
| 16:43:09 | bauzas | well, they would need to upgrade to latest 2023.1 release before they would see the log, hence my point | |
| 16:43:10 | sean-k-mooney | but they shoudl not just be looking at 27.0.0 before going to 29.0.0 | |
| 16:44:02 | sean-k-mooney | yep but i dont think we will ahve peopel upgradign for 27.0.0 directly to 29.0.0 without any updates to 27.x.y | |
| 16:44:09 | dansmith | I think backporting a reno to antelope is a good idea to increase our warning interval, but I do not think that buys us more time in terms of how soon we can do something | |
| 16:44:14 | sean-k-mooney | its a concern but i think its a minor one | |
| 16:44:15 | dansmith | because people may deploy a .0 and never update | |
| 16:44:37 | sean-k-mooney | maybe | |
| 16:44:46 | dansmith | meaning I don't think we can reasonably deprecate in 2023.2 and remove it in 2024.1 | |
| 16:44:48 | sean-k-mooney | but i think CVEs ectra would force an update | |
| 16:44:59 | dansmith | nobody is forced to update | |
| 16:45:24 | sean-k-mooney | ya what sucks is we agree do deprecate in antelope and we just forgot to merge the patch | |
| 16:45:31 | dansmith | IMHO, this is the extra work we take on by committing to the longer support envelope | |
| 16:45:31 | sean-k-mooney | because it was not assocated with any bug or blueprint | |
| 16:45:42 | bauzas | sean-k-mooney: we had quite the same situation in newton | |
| 16:45:45 | dansmith | yeah, sucks, but.. we just can't rewrite history | |
| 16:45:49 | bauzas | without that cadence | |
| 16:46:00 | bauzas | but we forgot something that merged post-rc1 | |
| 16:46:15 | bauzas | and I still remember the shitstorm that happened next | |
| 16:46:21 | bauzas | it's still engraved in me | |
| 16:46:26 | sean-k-mooney | so removal in 2024.2 it is i guess | |
| 16:46:43 | sean-k-mooney | assuming nothign happens btween now and then | |
| 16:47:01 | bauzas | I'd rather prefer to ask rosmaita again and the tc about the reno tooling things | |
| 16:47:22 | bauzas | to see whether we could forward port the deletion notes to B | |
| 16:47:30 | bauzas | brian's proposal was quite ok to me | |
| 16:47:45 | bauzas | but the tooling has to be correctly documented | |
| 16:48:01 | dansmith | that doesn't change anything about the decision, just the mechanics of the notice, to be clear | |
| 16:48:27 | bauzas | yup, that's why I'm still afraid of removing anything in B | |
| 16:48:37 | bauzas | the plan isn't sold yet | |
| 16:48:37 | dansmith | deprecating? | |
| 16:48:50 | dansmith | we can't remove these in B because we didn't warn about it | |
| 16:48:58 | bauzas | removing anything, and by extension deprecating (in this case) | |
| 16:49:01 | sean-k-mooney | ya like if we really wanted to we could just move the 2023.1 git tag so that 27.0.0 has the release note btu that has other problems so i dont really wnat to go there | |
| 16:49:16 | dansmith | no. | |
| 16:49:21 | sean-k-mooney | bauzas: ya not sure where removal is coming form in b | |
| 16:49:25 | bauzas | sean-k-mooney: well, we can't do this or then the distros would hate us | |
| 16:49:27 | sean-k-mooney | that is not what is beign proposed | |
| 16:49:37 | bauzas | sorry, I meant the general case | |
| 16:49:40 | sean-k-mooney | bauzas: hehe i know | |
| 16:50:03 | sean-k-mooney | but if we really wanted to get it in the 27.0.0 release notes im sure that possibel | |
| 16:50:29 | bauzas | I'm saying I'm still quite unhappy with any change proposing to deprecate or remove any thing in B, including in particular the hyperv driver that we speak | |
| 16:50:43 | sean-k-mooney | anyway i think we can likely move forward with the patch and waith for it to go out in 2024.1 | |
| 16:51:01 | sean-k-mooney | then see whtat the state is for 2024.2 and if its still functioanl at that point or not | |
| 16:51:31 | bauzas | dansmith: I haven't read the tc agenda for today, but do you think they will discuss the slurp things we discussed before the PTG ? | |
| 16:51:32 | sean-k-mooney | bauzas: i find it very unreasoonble to disallow deprecateion or removals in B | |
| 16:52:04 | bauzas | sean-k-mooney: my PTG concern is still legit, we haven't still a solid plan on forward-porting the notes to C | |
| 16:52:04 | sean-k-mooney | but i agree that we can only remove thing in B if they were deprecated in A or older | |
| 16:52:12 | dansmith | bauzas: neither have I so I dunno | |
| 16:53:02 | sean-k-mooney | sure but i dont think we should block the removal of deprecated fucntionalty on resolvign it | |
| 16:54:38 | dansmith | tbh, I'm not getting the problem here | |
| 16:54:52 | dansmith | we should backport a reno to 2023.1 about the deprecation, | |
| 16:55:14 | dansmith | we should have another one in 2024.1 for such a large thing | |
| 16:55:30 | dansmith | we should have a deprecation log message in 2023.1, 2023.2, 2024.1 | |
| 16:55:40 | dansmith | I think bauzas' concern is about remembering to do the extra reno in 2024.1, right? | |
| 16:55:41 | sean-k-mooney | yes bauzas and i swtiched topic slightly to talke about deprecation/removals in B in general | |
| 16:55:50 | bauzas | dansmith: correct | |
| 16:55:50 | sean-k-mooney | yes | |
| 16:55:57 | bauzas | dansmith: your plan looks good then | |
| 16:56:26 | bauzas | provided we don't forget to mention the deprecation in 2024.1 | |
| 16:56:32 | dansmith | sean-k-mooney: well, you seemed to go back to the specific with the "block removing on resolving" | |
| 16:56:43 | sean-k-mooney | well in 2024 we would be annouching that we intend to remvoe it effectivly | |
| 16:56:49 | sean-k-mooney | if that what we decied at that point | |
| 16:57:00 | sean-k-mooney | were as right now we are just saying its untested | |
| 16:57:13 | bauzas | sean-k-mooney: dansmith: I apologize, I mixed two problems | |
| 16:57:14 | dansmith | bauzas: to be honest, the removal of it is not that important, IMHO | |
| 16:57:21 | sean-k-mooney | and deprecated but no plan to remove it in any partical release | |
| 16:57:22 | bauzas | don't disagree | |
| 16:57:26 | bauzas | dansmith: ^ | |
| 16:57:29 | dansmith | bauzas: saying it's deprecated is a lot more important.. we can remove it when it becomes an _actual_ problem | |
| 16:57:35 | bauzas | true | |
| 16:57:46 | bauzas | ok, looks like we're settled then | |
| 16:57:48 | dansmith | which, if it's been long enough, doesn't matter when we do it | |
| 16:57:51 | bauzas | I can vote | |
| 16:59:05 | sean-k-mooney | anyway i need to go to another meeting now | |
| 16:59:25 | sean-k-mooney | bauzas: as an fyi i plan to submit the patch to remove the AZ filter next week when i have time to write it | |
| 16:59:44 | bauzas | ack | |
| 17:00:08 | sean-k-mooney | it was ment to be done like in xena or yoga. i have a version somewhere but im jsut going to do it from scratch | |
| 17:01:58 | bauzas | sean-k-mooney: you know that by merging this without having a tooling in place, we basically leave myself to be responsible of the release note forward-porting, right? :) | |
| 17:02:14 | bauzas | (just saying this here as well, as a side discussion occurs somewhere else) | |
| 17:09:46 | bauzas | https://review.opendev.org/c/openstack/nova/+/863910 is sent to the gate | |
| 17:12:15 | dansmith | so, | |
| 17:12:30 | dansmith | marking it as experimental back then made more sense than I think it does now | |
| 17:12:38 | dansmith | (I realize I'm +2 on that) | |
| 17:13:14 | dansmith | I think we do need to mark it as actually deprecated to be clean here, because we know it has no maintenance horizon, the dependent library is abandoned and in danger, etc | |
| 17:18:18 | sean-k-mooney | dansmith: we are technially doing both | |
| 17:18:27 | sean-k-mooney | its deprecated in the relesae notes | |
| 17:18:41 | dansmith | no it's not | |
| 17:18:42 | sean-k-mooney | but we use experimantal in the logs becasue we did not want to call it deprecated for reasons | |
| 17:18:52 | dansmith | https://review.opendev.org/c/openstack/nova/+/863910/1/releasenotes/notes/hyperv-experimental-antelope-372e18a05cafc295.yaml | |
| 17:18:59 | dansmith | it says "may be removed" but no | |
| 17:19:03 | dansmith | not "deprecated" | |
| 17:19:08 | sean-k-mooney | deprecations: | |
| 17:19:15 | sean-k-mooney | its in the deprecation section | |
| 17:19:25 | dansmith | meh | |
| 17:20:25 | dansmith | it's too vague at this point.. we should be saying it's deprecated and will be removed | |
| 17:20:46 | dansmith | the log is probably even more important than the reno | |
| 17:21:24 | dansmith | 2% of deployments are using hyperv...we really should not leave any room for misinterpreting what we know is going to happen | |
| 17:23:12 | sean-k-mooney | ok im fine with refining it but i was ok with the fact it was in the deprecation section to track that it was deprecated. | |
| 17:55:54 | opendevreview | Merged openstack/nova stable/yoga: Unify placement client singleton implementations https://review.opendev.org/c/openstack/nova/+/858997 | |
| 18:17:14 | opendevreview | Merged openstack/nova stable/yoga: Avoid n-cond startup abort for keystone failures https://review.opendev.org/c/openstack/nova/+/858998 | |