| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-18 | |||
| 16:28:30 | dansmith | bauzas: all the exit paths from that rebuild send a dedicated notification about the "phase" of the rebuild and I just didn't want to add a path that doesn't | |
| 16:28:53 | bauzas | I see your point | |
| 16:32:48 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (db) https://review.opendev.org/c/openstack/nova/+/831193 | |
| 16:32:49 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (objects) https://review.opendev.org/c/openstack/nova/+/839401 | |
| 16:32:49 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (manila abstraction) https://review.opendev.org/c/openstack/nova/+/831194 | |
| 16:32:50 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (drivers and compute manager part) https://review.opendev.org/c/openstack/nova/+/833090 | |
| 16:32:50 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (api) https://review.opendev.org/c/openstack/nova/+/836830 | |
| 16:32:51 | opendevreview | ribaudr proposed openstack/nova master: Check shares support https://review.opendev.org/c/openstack/nova/+/850499 | |
| 16:32:51 | opendevreview | ribaudr proposed openstack/nova master: Add metadata for shares https://review.opendev.org/c/openstack/nova/+/850500 | |
| 16:32:52 | opendevreview | ribaudr proposed openstack/nova master: Add instance.share_attach notification https://review.opendev.org/c/openstack/nova/+/850501 | |
| 16:32:52 | opendevreview | ribaudr proposed openstack/nova master: Add instance.share_detach notification https://review.opendev.org/c/openstack/nova/+/851028 | |
| 16:32:54 | opendevreview | ribaudr proposed openstack/nova master: Add shares to InstancePayload https://review.opendev.org/c/openstack/nova/+/851029 | |
| 16:32:54 | opendevreview | ribaudr proposed openstack/nova master: Add helper methods to attach/detach shares https://review.opendev.org/c/openstack/nova/+/852085 | |
| 16:32:56 | opendevreview | ribaudr proposed openstack/nova master: Add libvirt test to ensure metadata are working. https://review.opendev.org/c/openstack/nova/+/852086 | |
| 16:32:56 | opendevreview | ribaudr proposed openstack/nova master: Add virt/libvirt error test cases https://review.opendev.org/c/openstack/nova/+/852087 | |
| 16:32:58 | opendevreview | ribaudr proposed openstack/nova master: Add share_info parameter to reboot method for each driver (driver part) https://review.opendev.org/c/openstack/nova/+/854823 | |
| 16:32:58 | opendevreview | ribaudr proposed openstack/nova master: Support rebooting an instance with shares (compute and API part) https://review.opendev.org/c/openstack/nova/+/854824 | |
| 16:33:00 | opendevreview | ribaudr proposed openstack/nova master: Add instance.share_attach_error notification https://review.opendev.org/c/openstack/nova/+/860282 | |
| 16:33:00 | opendevreview | ribaudr proposed openstack/nova master: Add instance.share_detach_error notification https://review.opendev.org/c/openstack/nova/+/860283 | |
| 16:33:02 | opendevreview | ribaudr proposed openstack/nova master: Add share_info parameter to resume method for each driver (driver part) https://review.opendev.org/c/openstack/nova/+/860284 | |
| 16:33:02 | opendevreview | ribaudr proposed openstack/nova master: Support resuming an instance with shares (compute and API part) https://review.opendev.org/c/openstack/nova/+/860285 | |
| 16:33:04 | opendevreview | ribaudr proposed openstack/nova master: Add helper methods to rescue/unrescue shares https://review.opendev.org/c/openstack/nova/+/860286 | |
| 16:33:04 | opendevreview | ribaudr proposed openstack/nova master: Support rescuing an instance with shares (driver part) https://review.opendev.org/c/openstack/nova/+/860287 | |
| 16:33:06 | opendevreview | ribaudr proposed openstack/nova master: Support rescuing an instance with shares (compute and API part) https://review.opendev.org/c/openstack/nova/+/860288 | |
| 16:33:06 | opendevreview | ribaudr proposed openstack/nova master: Docs about Manila shares API usage https://review.opendev.org/c/openstack/nova/+/871642 | |
| 16:33:08 | opendevreview | ribaudr proposed openstack/nova master: Mounting the shares as part of the initialization process https://review.opendev.org/c/openstack/nova/+/880075 | |
| 16:38:44 | sean-k-mooney | bauzas: we missed talking about the release note for hyperv and vmawre experimental/deprecated status | |
| 16:38:54 | sean-k-mooney | or more speicifclly backporting that to antelope | |
| 16:39:05 | bauzas | shit | |
| 16:39:18 | bauzas | my brain derailed | |
| 16:39:49 | sean-k-mooney | so i would obviosly like to do both (merge on master and backport) | |
| 16:40:00 | sean-k-mooney | so that the warning goes out early | |
| 16:40:15 | sean-k-mooney | and then wait and see what happens with os-win before doing anythin else | |
| 16:41:15 | sean-k-mooney | if the TC retrie os-win in bobcat then we can look at remvoing the supprot in 2024.1 | |
| 16:42:09 | bauzas | sean-k-mooney: my only concern is that the relnotes for 27.0.0 won't see it | |
| 16:42:10 | sean-k-mooney | as long as its not breaking any ci jobs and we have sent the warning i dont think thre is any pressure on us to do anything else | |
| 16:42:13 | bauzas | show* | |
| 16:42:27 | bauzas | so operators may miss it | |
| 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 | |