| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-11 | |||
| 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 | |
| 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 | |
| 09:43:16 | noonedeadpunk | So first question - when `discover_hosts_in_cells_interval` is set to -1, I assume you need to run `nova-manage cell_v2 discover_hosts` before compute will appear in `openstack compute service list`? | |
| 09:43:42 | noonedeadpunk | As I can recall that compute itself does report back on startup as well | |
| 09:43:47 | sean-k-mooney | noonedeadpunk: no they will show up in the list | |
| 09:43:54 | noonedeadpunk | and this option is for scheduler | |
| 09:43:54 | sean-k-mooney | but they wont be in the cell mappings | |
| 09:43:58 | bauzas | noonedeadpunk: no, but they won't be scheduled | |
| 09:44:09 | bauzas | since they won't have a cell mapping | |
| 09:44:16 | bauzas | haha | |
| 09:44:16 | noonedeadpunk | aha, gotcha | |
| 09:44:47 | sean-k-mooney | discover_hosts tell use which rabbit to use to talk to the compute and what cell db its in | |
| 09:44:52 | noonedeadpunk | ok, then we have this set correctly :D | |
| 09:45:14 | noonedeadpunk | but it discovers... through API? | |
| 09:45:21 | noonedeadpunk | not through conductor then? | |
| 09:45:21 | sean-k-mooney | no | |
| 09:45:28 | noonedeadpunk | ah, right | |