| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-11 | |||
| 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 | |
| 09:45:29 | sean-k-mooney | it discovers by connecting to all the cell dbs | |
| 09:45:34 | noonedeadpunk | ok-ok, yes, I recalled :) | |
| 09:46:38 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L1043 | |
| 09:46:40 | sean-k-mooney | calls https://github.com/openstack/nova/blob/ae42400b7663bc58d5562de99e976c95131b77a9/nova/objects/host_mapping.py#L247-L285 | |
| 09:47:02 | noonedeadpunk | and in order for compute to be discovered by discover_hosts it must already be in service list? | |
| 09:47:12 | opendevreview | Merged openstack/placement master: Db: Drop redundant indexes for columns already having unique constraint https://review.opendev.org/c/openstack/placement/+/856770 | |
| 09:47:14 | sean-k-mooney | correct | |
| 09:47:26 | sean-k-mooney | so the compute agent connects to the conducotr on startup | |
| 09:47:47 | sean-k-mooney | and then it ask the conductor to register a service in the db | |
| 09:48:01 | sean-k-mooney | "the cell db" | |