| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-11 | |||
| 17:49:49 | opendevreview | ribaudr proposed openstack/nova master: The purpose of this patch is to ensure that, in the event of a compute reboot, shares associated with instances are mounted successfully on the compute host during the service initialization process. https://review.opendev.org/c/openstack/nova/+/880075 | |
| 18:54:40 | dansmith | bauzas: I totally missed this, but apparently we should be working to remove hyperv: https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html | |
| 19:03:20 | sean-k-mooney | oh ya | |
| 19:03:24 | sean-k-mooney | i rememebr seeing that | |
| 19:04:07 | sean-k-mooney | so ya we proably should deprecate it this cycle | |
| 19:04:12 | sean-k-mooney | and remove in C | |
| 19:04:29 | sean-k-mooney | ... or D with the new lifecycle | |
| 19:04:45 | sean-k-mooney | that kind of sucks as it proably should have been deprecated in A | |
| 19:05:02 | gmann | if os-win goes away in this cyle then we might need to just remove it ? | |
| 19:05:13 | sean-k-mooney | yep | |
| 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 | gmann | humm, and no removal soon or when we decide to remove then go with deprecation first and then removal ? | |
| 19:38:25 | sean-k-mooney | i was looking for that message eiarler by the way | |
| 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 | nova.boot_servers: 18.803 sec (Avg) | |
| 09:36:32 | manuvakery1 | make the server count to 5 added a huge difference in delete server | |
| 09:36:32 | manuvakery1 | nova.delete_servers: 14.675 sec (Avg) | |
| 09:36:32 | manuvakery1 | nova.boot_servers : 11.941 sec (Avg) | |
| 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:33 | manuvakery1 | is this expected? | |
| 09:36:33 | manuvakery1 | nova.delete_servers: 42.988 sec (Avg) | |
| 09:37:14 | manuvakery1 | the compute nodes are not under any load | |