| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-11 | |||
| 19:05:27 | sean-k-mooney | can we retoactivly declare it deprecated for Antelope | |
| 19:05:37 | sean-k-mooney | assuming that happens | |
| 19:05:42 | gmann | humm | |
| 19:06:48 | sean-k-mooney | either way we shoudl declare it deprecated in bobcat | |
| 19:06:57 | sean-k-mooney | and see if we have issues with os-win | |
| 19:08:53 | bauzas | dansmith : we can send a deprecation signal by Bobcat if you want but continue to say it then in C | |
| 19:10:11 | gmann | even TC is reaching out operators if anyone using/have window based customer and can maintain the project/project-deps and will take final call on retirement of os-win in June event or so | |
| 19:10:58 | dansmith | IIRC, we already said that vmware was abandonware right? | |
| 19:11:05 | gmann | but from nova perspective, if we do not/have not seen much interest in hyperV then deprecating ASAP might be good. and if os-win retirement happen in this cycle then removal also in B only | |
| 19:11:12 | dansmith | so I feel like we could do the same for hyperv for the time being and then remove it according to our schedule | |
| 19:11:23 | bauzas | dansmith: yup we deprecated it IIRC | |
| 19:11:25 | gmann | yeah | |
| 19:11:53 | dansmith | yeah, so no need to freak out and yank it early, IMHO, just mark as deprecated, even if it can't run or fails with os-win problems and then we can remove it in D | |
| 19:12:13 | dansmith | the thing that concerns me the most however is the user survey showing 2% of users are using it | |
| 19:12:36 | dansmith | which, deprecation aside, also worries me :) | |
| 19:14:00 | sean-k-mooney | i woudl hope that existing deployment can continue to use the last release of os-win | |
| 19:14:14 | gmann | we can un-deprecate it if anyone come and maintain it. but I am worried that they might see this deprecation way after few cycle when they upgrade it to B and we might hve removed it by then | |
| 19:14:17 | sean-k-mooney | the issue will be with new python releases or its deps | |
| 19:14:59 | sean-k-mooney | well we would not remove it until D | |
| 19:15:14 | sean-k-mooney | unless we are forced to earlier | |
| 19:15:17 | gmann | that is question on how we want to do for supported stable branch, retirement means it goes away from supported releases also and what to tell on hyperV on stable is another challenges | |
| 19:15:36 | sean-k-mooney | we dont test hyperv in the first party ci | |
| 19:15:57 | gmann | yeah | |
| 19:15:59 | sean-k-mooney | so it really only affect stable branches if we fix a bug and want to backport it | |
| 19:16:46 | gmann | yeah, in case of stable broken on any fixes or so | |
| 19:17:12 | gmann | os-win stable is broken and then no way to fix it | |
| 19:18:28 | gmann | but deprecating it now is best we can do | |
| 19:22:56 | gmann | bauzas: dansmith: vmware driver is un-deprecated since victoria https://review.opendev.org/c/openstack/nova/+/742407 | |
| 19:23:08 | sean-k-mooney | gmann: we redeprecated it again | |
| 19:23:19 | dansmith | lol | |
| 19:23:24 | dansmith | it has been so many times | |
| 19:23:36 | gmann | oh | |
| 19:24:24 | gmann | where is the latest deprecation ? | |
| 19:24:39 | sean-k-mooney | maybe im mistaken but i tought we did it in yoga? | |
| 19:24:58 | dansmith | that would have been the next release | |
| 19:26:21 | gmann | I cannot see if we re-deprecated after 742407 | |
| 19:26:45 | sean-k-mooney | hum well ciwatch.mmedvede.net/project?project=nova&time=7+days seams to nolonger be working | |
| 19:26:58 | sean-k-mooney | has the third party ci been maintianed | |
| 19:27:47 | sean-k-mooney | http://207.189.188.190/logs/ | |
| 19:28:12 | sean-k-mooney | im not seeing anything | |
| 19:28:47 | sean-k-mooney | https://review.opendev.org/q/commentby:vmwareminesweeper | |
| 19:28:53 | sean-k-mooney | ok so tehre are comments i gues | |
| 19:29:53 | sean-k-mooney | althouhg im not sure that is recent | |
| 19:31:26 | gmann | yeah, it seems it is not deprecated, I can see a few changes merged also in driver (last merged in Apr 29, 2022) so it is maintained ? :) | |
| 19:35:04 | sean-k-mooney | i think no | |
| 19:35:20 | sean-k-mooney | the undeprecation was condtional on them maintining the ci | |
| 19:35:30 | sean-k-mooney | it looks like it was shut down in april 2022 | |
| 19:37:25 | gmann | this is what i found from melwitt topic in antelope PTG discussion, mark it as "not tested" explicitly https://etherpad.opendev.org/p/nova-antelope-ptg#L216 | |
| 19:37:42 | sean-k-mooney | ah yes i rememebr that | |
| 19:37:49 | sean-k-mooney | we wanted to not use the term deprecated | |
| 19:38:25 | sean-k-mooney | i was looking for that message eiarler by the way | |
| 19:38:25 | gmann | humm, and no removal soon or when we decide to remove then go with deprecation first and then removal ? | |
| 19:38:44 | gmann | ok | |
| 19:39:16 | sean-k-mooney | i think we left it at if it breaks we are not goignt to fix it unless someone comes with a patch | |
| 19:39:17 | gmann | i think for hyperV we can mark it deprecated as its deps going away soon.... | |
| 19:39:28 | gmann | sean-k-mooney: k | |
| 19:39:29 | sean-k-mooney | but no one should deploy new installs with vmware | |
| 19:40:47 | sean-k-mooney | we proably need to actully do what we agreed there since im not seeing either a flag on the dirver or the message | |
| 19:40:50 | sean-k-mooney | in the logs | |
| 19:41:12 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/863911 | |
| 19:41:19 | sean-k-mooney | we should have merged that | |
| 19:41:23 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/863910/1 | |
| 19:41:29 | sean-k-mooney | and that in Antielope | |
| 19:41:36 | sean-k-mooney | i knew stephen had patches for this | |
| 19:42:12 | sean-k-mooney | bauzas: ^ we missed inclucing those | |
| 19:42:46 | sean-k-mooney | gmann: i think we should consider backporting those to stable/antelope | |
| 19:42:54 | gmann | i see | |
| 19:43:48 | gmann | sean-k-mooney: this 'not tested' is good to backport but for HyperV case we need to mark deprecated instead of experimental | |
| 19:44:45 | sean-k-mooney | i would prefer to do that as a third patch just to keep that discussion sperate form addign the warning | |
| 19:45:17 | sean-k-mooney | gmann: from a release note point of view both of these we going to be deprecations | |
| 19:45:32 | gmann | sure, that works fine. and we can backport this 'note tested' warning to reflect the actual things | |
| 19:45:43 | sean-k-mooney | we just didnt want to use that trem in the warning | |
| 19:46:00 | sean-k-mooney | basically we wanted to have the ablity to remove in b or C if needed | |
| #openstack-nova - 2023-04-12 | |||
| 06:48:11 | opendevreview | Sam Morrison proposed openstack/nova master: Filter out deleted instances when looking for build timouts https://review.opendev.org/c/openstack/nova/+/880125 | |
| 08:17:20 | bauzas | dansmith: gmann: sean-k-mooney: I added my thoughts on the deprecation patches but I'm afraid of the fact a backport wouldn't help operators to notice | |
| 08:48:13 | opendevreview | Jorge San Emeterio proposed openstack/nova master: WIP: Testing whether tests on bug#1998148 still fail. https://review.opendev.org/c/openstack/nova/+/880135 | |
| 09:05:44 | Uggla | bauzas , hi, if you have some time, can you have a look at the virtiofs series and especially the interfaces ? | |
| 09:06:10 | bauzas | sure I've seen your updates | |
| 09:06:30 | bauzas | but I need a jar of coffee first | |
| 09:34:25 | sean-k-mooney | Uggla: have you moved the libvirt driver changes for creating the xml config to the start fo the series | |
| 09:34:52 | sean-k-mooney | that should be the first set of patches in the serise so that can be merged to allow scaphanda work to start in parallel | |
| 09:35:08 | sean-k-mooney | while we wait for manialla to add the lock api | |
| 09:36:32 | manuvakery1 | Hi, I have a 2 node cluster and I am running a rally scenario against it to create and delete servers. When i set the server count to 2 I see the response time as follows | |
| 09:36:32 | manuvakery1 | nova.boot_servers : 11.941 sec (Avg) | |
| 09:36:32 | manuvakery1 | nova.delete_servers: 14.675 sec (Avg) | |
| 09:36:32 | manuvakery1 | make the server count to 5 added a huge difference in delete server | |
| 09:36:32 | manuvakery1 | nova.boot_servers: 18.803 sec (Avg) | |
| 09:36:33 | manuvakery1 | nova.delete_servers: 42.988 sec (Avg) | |
| 09:36:33 | manuvakery1 | is this expected? | |
| 09:37:14 | manuvakery1 | the compute nodes are not under any load | |
| 09:37:49 | Uggla | sean-k-mooney, hum, not really. | |
| 09:40:45 | sean-k-mooney | ok im not sure when we disucssed that | |
| 09:41:05 | kashyap | bauzas: Do we have a conclusion on this? -- https://review.opendev.org/c/openstack/nova/+/879021 | |
| 09:41:28 | sean-k-mooney | but if we want to merge any code before the manial api is implmented the libvirt dirver chage for the xml generation is the lowest risk | |
| 09:42:09 | bauzas | sean-k-mooney: I haven't went more than the 4th change, but the Manila API should be the last change in the series | |
| 09:42:10 | noonedeadpunk | hey folks! We're reviewing our nova role, as we haven't touched in for a while, and now a bit /o\ about logic we have there. so would be glad if you can share your prespective on some things :) | |
| 09:42:34 | sean-k-mooney | bauzas: yes the api should be last and the xml change sin the drive rhsould be first | |
| 09:42:51 | sean-k-mooney | driver then db then rpc finaly api | |
| 09:42:55 | bauzas | sean-k-mooney: for the libvirt driver, meh to me, since I think we should be quite okay for the 4 first patches (DB and objects) | |
| 09:43:14 | bauzas | noonedeadpunk: shoot | |