| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-09-12 | |||
| 16:17:55 | bauzas | #topic Open discussion | |
| 16:18:00 | bauzas | I have one | |
| 16:18:04 | bauzas | (bauzas) Can't chair next meeting, who else ? | |
| 16:18:04 | bauzas | (bauzas) Can't chair next meeting, who else ? | |
| 16:18:37 | bauzas | (I'll need to attend a parent-teacher meeting for my daughter's class next week) | |
| 16:19:04 | bauzas | so, any volunteer ? | |
| 16:19:18 | gibi | if nobody else then I will | |
| 16:19:33 | bauzas | 1.. | |
| 16:19:37 | sean-k-mooney | i have i have one or two topics to bring up quickly. thanks gibi | |
| 16:20:00 | bauzas | sean-k-mooney: you mean, you appreciate gibi for chairing next week ? :) | |
| 16:20:06 | sean-k-mooney | yes | |
| 16:20:10 | bauzas | cool | |
| 16:20:12 | bauzas | 2.. | |
| 16:20:14 | bauzas | 3.. | |
| 16:20:16 | bauzas | sold | |
| 16:20:25 | bauzas | #info gibi will chair next week's meeting | |
| 16:20:29 | sean-k-mooney | i could proably do it if he is not around for any reason i just dont want too :) | |
| 16:20:36 | gibi | sure I will do it | |
| 16:20:42 | bauzas | sean-k-mooney: shoot your own topics (even if I can guess one) | |
| 16:20:58 | sean-k-mooney | first one is this stable only patch that we agreed to do a year ago | |
| 16:21:00 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/828979 | |
| 16:21:07 | sean-k-mooney | im reviewing it now | |
| 16:21:10 | sean-k-mooney | and it looks ok | |
| 16:21:20 | sean-k-mooney | so just wanted to highlight it to others | |
| 16:21:38 | sean-k-mooney | the second quetion is semi procedural | |
| 16:21:42 | bauzas | want it for Bobcat ? | |
| 16:21:50 | bauzas | nvm, stupid me | |
| 16:22:01 | sean-k-mooney | its for victoria | |
| 16:22:05 | bauzas | yeah, hence me stupid | |
| 16:22:22 | sean-k-mooney | so second question is we were discussing on the mailing list about removing the hyperv driver | |
| 16:22:29 | sean-k-mooney | and vmeare next cycle | |
| 16:22:36 | bauzas | yeah and I provided my humble guts | |
| 16:22:46 | sean-k-mooney | we can chat about that in the ptg if needed | |
| 16:22:55 | sean-k-mooney | but i was wondering do we need a spec | |
| 16:23:02 | bauzas | which are, unless extremely necessary, avoid any virt driver deprecation this cycle | |
| 16:23:07 | sean-k-mooney | or just come to agreement and specless blueprint | |
| 16:23:08 | bauzas | s/deprecation/removal | |
| 16:23:27 | bauzas | for removing those from our tree ? | |
| 16:23:35 | sean-k-mooney | we deprecated them in antileop and marked them experimental | |
| 16:23:45 | sean-k-mooney | so in caracal i want to remove them form the nova tree | |
| 16:23:47 | bauzas | yeah I know hence my sedf | |
| 16:24:17 | gibi | I don't think we need a spec to delete things | |
| 16:24:21 | bauzas | yeah, so, procedurally, I'd say "mail ML ops" wins against any other paperwork | |
| 16:24:40 | bauzas | I just want the ops to be aware of the cut | |
| 16:24:52 | bauzas | and yeah, it doesn't require a blueprint | |
| 16:24:55 | bauzas | a relnote, for sure | |
| 16:25:17 | gmann | bauzas: sean-k-mooney I am planning the hyperv removal and other os-win cleanup/retirement in 2024.1 only | |
| 16:25:18 | bauzas | this is just a removal patch | |
| 16:25:20 | sean-k-mooney | ok well we can chat about it more in the ptg i guess and send a mail to that list | |
| 16:25:29 | bauzas | but yeah, communication matters | |
| 16:25:38 | gmann | this is whole stack #link https://review.opendev.org/q/topic:retire-winstackers | |
| 16:25:39 | sean-k-mooney | gmann: yep this is all in the context of 2024.1 | |
| 16:25:45 | gmann | yeah | |
| 16:25:51 | sean-k-mooney | i just wanted to know how to track this | |
| 16:25:58 | gmann | and I need to add a spec also as it impact one API too | |
| 16:26:17 | gmann | so all those we can discuss together in PTG | |
| 16:26:21 | bauzas | when we removed nova-net, this wasn't tracked by a blueprint | |
| 16:26:25 | gmann | sean-k-mooney: yeah, will add BP and spec | |
| 16:26:37 | bauzas | and this was having API implications | |
| 16:26:50 | sean-k-mooney | im not sure what api impact this will have | |
| 16:27:03 | gmann | I will propose that, its rdp console I think | |
| 16:27:08 | bauzas | tbc, I don't want us to paperwork any removal | |
| 16:27:20 | sean-k-mooney | ah rdp | |
| 16:27:27 | bauzas | a deprecation for sure, but this was communicated way in advance | |
| 16:27:30 | sean-k-mooney | i think that kind of seperate | |
| 16:27:34 | gmann | spec is worth here so that we do not miss anything | |
| 16:27:54 | sean-k-mooney | it should be sperate commits at least but ok | |
| 16:27:55 | gmann | especially API change point of view | |
| 16:27:56 | bauzas | then, I defer this discussion to the PTG | |
| 16:28:01 | sean-k-mooney | i think we can wrap the meeting there | |
| 16:28:05 | bauzas | we need more contact | |
| 16:28:08 | bauzas | context | |
| 16:28:10 | bauzas | doh | |
| 16:28:12 | gmann | sure, will propose the spec meanhwile and can discuss in PTG | |
| 16:28:22 | bauzas | sean-k-mooney: wanted to discuss the SQLA 1.4 backref thing ? | |
| 16:28:35 | sean-k-mooney | am i kind of forgot | |
| 16:28:51 | sean-k-mooney | so stephen has updated the patchs to address the comment you raised | |
| 16:28:51 | bauzas | to be frank, I already made a round of reviews | |
| 16:29:14 | bauzas | so, yeah, this is best effort, but I have some space for this | |
| 16:29:35 | bauzas | if we can have this quickwin, let's aim it | |
| 16:29:45 | bauzas | but we absolutely need to be on par with the existing | |
| 16:30:26 | bauzas | that's why I'm OK with changing our description of the relationships in B, but not drop anything until C | |
| 16:30:36 | sean-k-mooney | ack. i would be sad if this isnt included as to me it was a cycle priroty but yes. i belive the issue you raised was not actully something we needed to adress | |
| 16:30:44 | sean-k-mooney | but stephen has updated it | |
| 16:31:03 | sean-k-mooney | there are no drops in the serises | |
| 16:31:06 | bauzas | sean-k-mooney: well, instance.block_device_mapping may have returned the deleted BDMs after this patch | |
| 16:31:20 | sean-k-mooney | no | |
| 16:31:21 | bauzas | sean-k-mooney: there are, last patch of 34 | |
| 16:31:24 | bauzas | 3* | |
| 16:31:43 | sean-k-mooney | i think stephen was correct that tnat version of the relaation was unused | |
| 16:31:52 | sean-k-mooney | but again that has been fixed in the current version | |
| 16:32:11 | sean-k-mooney | and stephen added a 3rd patch to remove the possible unused relationship mapping | |
| 16:32:21 | sean-k-mooney | in any case lets just review it as normal | |
| 16:32:23 | bauzas | that's what I'm saying | |
| 16:32:34 | bauzas | I don't bet on things we may not use | |
| 16:32:55 | bauzas | particularly by relying on our CI to claim whether this is in use or not | |
| 16:33:20 | bauzas | so, I'm OK with doing this kind of dumb rewriting of the relationships we have | |
| 16:33:30 | bauzas | without touching them or asserting anything | |
| 16:33:36 | bauzas | in B | |
| 16:33:55 | bauzas | while in C, we may debate on the optimizations we may do | |