| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-10-13 | |||
| 11:37:52 | sean-k-mooney | gibi: so im not sure that they do but i could print all of the notificaiotn object i guess | |
| 11:38:07 | sean-k-mooney | see what they are | |
| 11:38:12 | gibi | yeah that could help | |
| 11:44:03 | songwenping_ | sean-k-mooney, gibi: when does nova-scheduler update host aggregate map, change host from aggregate? | |
| 11:46:16 | gibi | sean-k-mooney: I checked 3 reproduction form the gate, it is always nova.tests.functional.test_servers.ServersTestV219.test_description_errors test case logs that mentions the same instance uuid as the failed unshelve test case | |
| 11:46:47 | gibi | songwenping_: I don't know without looking into the code, sorry | |
| 11:47:03 | sean-k-mooney | gibi: interesting so to repoduce this we shoudl run both of those tests | |
| 11:47:31 | sean-k-mooney | it does sound like we are sharing global state some how | |
| 11:48:31 | gibi | sean-k-mooney: yeah, it is alway 61 seconds after the succesfull run of .ServersTestV219.test_description_errors that the unshelve test fails | |
| 11:48:51 | gibi | that sounds like a 60 sec timout on an RPC | |
| 11:49:02 | songwenping_ | thanks gibi. :( | |
| 11:49:16 | gibi | songwenping_: sorry I knee deep in someting else at the moment | |
| 11:50:02 | sean-k-mooney | songwenping_: nova does not move host between aggreates. you have to use the api to do that | |
| 11:50:03 | gibi | sean-k-mooney: so my assumption is that the test_description_errors case does not end cleanly | |
| 11:50:30 | sean-k-mooney | songwenping_: i dont think we cache that infor in the scheduler its not part of the host state objects | |
| 11:50:43 | sean-k-mooney | songwenping_: so once its commited to the db i think the schduler will see it | |
| 11:52:00 | songwenping_ | sean-k-mooney: nova-scheduler update part of these hosts. | |
| 11:54:25 | sean-k-mooney | songwenping_: im not sure what you mean by that | |
| 11:54:56 | sean-k-mooney | the nova scedular nerver modfies aggreates or compute nodes | |
| 11:55:23 | sean-k-mooney | it just makes claims in plcement and selesct the destionation for instances | |
| 11:55:53 | sean-k-mooney | aggreate membership si entrily mange extrenally by the nova-api | |
| 11:55:56 | songwenping_ | sean-k-mooney: nova-scheduler update its host_aggregate_map attribute | |
| 11:56:23 | songwenping_ | nova-api change the aggregate's host | |
| 11:56:55 | songwenping_ | let me debug on my env first. | |
| 11:58:11 | sean-k-mooney | what release of openstack are you using | |
| 11:58:25 | songwenping_ | R | |
| 11:58:30 | sean-k-mooney | rocky | |
| 11:58:33 | songwenping_ | yes | |
| 11:58:48 | sean-k-mooney | im not sure that exist in the host manager anymore | |
| 11:59:43 | sean-k-mooney | ok it does | |
| 11:59:45 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L353 | |
| 12:00:15 | sean-k-mooney | its plural host_aggregates_map not host_aggregate_map | |
| 12:00:43 | songwenping_ | yes sorry | |
| 12:01:14 | sean-k-mooney | so its called here https://github.com/openstack/nova/blob/7b063e4d0518af3e57872bc0288a94edcd33c19d/nova/scheduler/manager.py#L662-L670 | |
| 12:02:13 | sean-k-mooney | which is called in a number of places in tghe compute api https://github.com/openstack/nova/blob/7b063e4d0518af3e57872bc0288a94edcd33c19d/nova/compute/api.py#L6231 | |
| 12:02:51 | sean-k-mooney | this is where we update it when you add a host https://github.com/openstack/nova/blob/7b063e4d0518af3e57872bc0288a94edcd33c19d/nova/compute/api.py#L6414 | |
| 12:04:05 | sean-k-mooney | songwenping_: so we update it after we update it in the db but before we update it in placment | |
| 12:04:44 | sean-k-mooney | songwenping_: so if you are using placment for aggres there is a very short period of time where the host is a member of an aggreate but placment doe snot know yet | |
| 12:04:56 | sean-k-mooney | however all of this happens before the api request returns | |
| 12:05:42 | songwenping_ | yeah, but the host param seems a single once | |
| 12:06:18 | sean-k-mooney | the invocation of the schduler metohd is a cast | |
| 12:06:33 | sean-k-mooney | so it might take a while after we retrun for that to propageate and the schdulers to update | |
| 12:10:59 | songwenping_ | sean-k-moony: not exactly, we wait a long time. | |
| 12:12:18 | sean-k-mooney | songwenping_: what is the actul problem you are seeing | |
| 12:12:34 | sean-k-mooney | have you filed a bug describing it with logs | |
| 12:12:50 | songwenping_ | not yet, i am not sure | |
| 12:12:51 | sean-k-mooney | i currently on a call so i dont really have time to help debug it now | |
| 12:13:09 | songwenping_ | no hurry. | |
| 12:14:55 | songwenping_ | i am debugging now. | |
| 12:48:46 | gibi | sean-k-mooney: seems test_description_errors can fail and leave running greenthreads behind: https://paste.opendev.org/show/809966/ | |
| 12:49:00 | gibi | I mean can produce an error without the testcase failing | |
| 12:49:09 | gibi | then leaking running greanthreads | |
| 12:49:10 | sean-k-mooney | i see | |
| 12:49:26 | sean-k-mooney | ok and i guess that can somehow impact other tests | |
| 12:50:02 | gibi | yeah it is still strange how these tests interact. there is a global state somewhere | |
| 12:50:17 | sean-k-mooney | could there somehow be sharing betwen the fake_impl for oslo.messaging | |
| 12:51:28 | sean-k-mooney | or the db fixture. it seams like somehost when those finally time out it trigres the db to be cleaned up | |
| 12:53:09 | sean-k-mooney | or i guess the notifcation fixture but really im just speculating | |
| 12:53:35 | gibi | I dig forward.. | |
| 12:53:39 | sean-k-mooney | at least we have something to investigate | |
| 12:54:50 | gibi | yeah | |
| 13:03:54 | opendevreview | Federico Ressi proposed openstack/nova master: Debug Nova APIs call failures https://review.opendev.org/c/openstack/nova/+/806683 | |
| 13:04:22 | opendevreview | Federico Ressi proposed openstack/nova master: Check Nova project changes with Tobiko scenario test cases https://review.opendev.org/c/openstack/nova/+/806853 | |
| 13:18:50 | kashyap | sean-k-mooney: I haven't checked the specs and the Git logs yet - do you recall what's the status of vDPA in upstream Nova? | |
| 13:19:33 | sean-k-mooney | we have partial support | |
| 13:19:42 | sean-k-mooney | we do not support any move operations | |
| 13:19:50 | sean-k-mooney | and we only support it for netwok devices | |
| 13:19:53 | kashyap | Ah, right - no move support | |
| 13:20:02 | sean-k-mooney | with ovs hardware offload | |
| 13:21:03 | sean-k-mooney | e.g. we do not support vdpa in legacy mode only in switchdev mode and the sriovnic_agent only support legacy mode | |
| 13:21:33 | sean-k-mooney | so you cant use vdpa with openstack without ovs as the contol plane using tcflower to instll flow into the nic | |
| 13:21:56 | sean-k-mooney | kashyap: was there a resaond you wanted to know | |
| 13:22:24 | sean-k-mooney | for our product it will be tech previwe in 17 until we can actully support at least some of the move ops | |
| 13:22:38 | kashyap | sean-k-mooney: Not for product - I was curious from an upstream PoV | |
| 13:23:03 | sean-k-mooney | i may add more support this cycle but hardware has been a limiting factor to working on this | |
| 13:23:04 | kashyap | The reason was just I was reading about vDPA and it reminded me of it | |
| 13:23:25 | sean-k-mooney | ack | |
| 14:23:33 | sean-k-mooney | does this look familar to anyone | |
| 14:23:35 | sean-k-mooney | https://paste.opendev.org/show/809977/ | |
| 14:23:46 | sean-k-mooney | ] GET /placement/resource_providers?in_tree=4838f356-678a-477c-a2b8-7a743ad0842c => generated 162 bytes in 5 msecs (HTTP/1.1 404) | |
| 14:24:11 | sean-k-mooney | but in the debug logs the path is wrong | |
| 14:24:12 | sean-k-mooney | 92.168.1.10 "GET /placemen//resource_providers?in_tree=4838f356-678a-477c-a2b8-7a743ad0842c" status: 404 | |
| 14:25:39 | sean-k-mooney | the apach2 config just has ProxyPass "/placement" "unix:/var/run/uwsgi/placement-api.socket|uwsgi://uwsgi-uds-placement-api/" retry=0 | |
| 14:26:41 | sean-k-mooney | this is causeing "/usr/local/bin/nova-status --config-file /etc/nova/nova.conf upgrade check" to fail which breaks devstack | |
| 14:26:57 | alecorps | hello | |
| 14:27:44 | alecorps | is someone can have a look to the PR 808791 ? | |
| 14:28:14 | sean-k-mooney | PR as in pull request | |
| 14:28:21 | gibi | sean-k-mooney: you have wrong config in you apache proxy | |
| 14:28:24 | gibi | sean-k-mooney: in devstack | |
| 14:28:32 | gibi | sean-k-mooney: searching for the commit... | |
| 14:28:49 | gibi | sean-k-mooney: https://review.opendev.org/c/openstack/devstack/+/811303 | |
| 14:28:51 | sean-k-mooney | gibi: i guess i need to pull devstack? | |
| 14:28:59 | gibi | probably yes | |
| 14:29:15 | gibi | you need the above fix is you have a new enough apache | |
| 14:29:24 | sean-k-mooney | oh ok | |
| 14:29:31 | sean-k-mooney | it removed the / on the socket | |
| 14:30:37 | sean-k-mooney | alecorps: what is PR 808791 | |
| 14:30:56 | alecorps | https://review.opendev.org/c/openstack/nova/+/808791 | |
| 14:31:00 | alecorps | yes pull request :) | |
| 14:31:06 | alecorps | sorry | |