| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-06-28 | |||
| 11:48:48 | sean-k-mooney | we wont create a second binding | |
| 11:48:54 | sean-k-mooney | we will just update the host-id | |
| 11:49:20 | sean-k-mooney | but if neutron is still binding it form the first failed attempet we woudl get a concurrent error | |
| 11:49:39 | sean-k-mooney | frickler: did you check the logs to see if the vm was retired on a second host? | |
| 11:51:55 | frickler | sean-k-mooney: it is a single-node job, I would be surprised if that happened | |
| 11:53:38 | sean-k-mooney | frickler: ok well the only other thing i can think of is the client retry | |
| 11:54:03 | sean-k-mooney | ralonsoh: could this happen if nova retryed creating the port binding because thet inital call timed out | |
| 11:54:08 | sean-k-mooney | i think we try 3 times | |
| 11:54:54 | sean-k-mooney | this being "Concurrent port binding operations failed on port ..." | |
| 12:19:57 | opendevreview | Balazs Gibizer proposed openstack/nova master: Add regression test for bug 1838392 https://review.opendev.org/c/openstack/nova/+/847965 | |
| 13:08:13 | bauzas | gibi: sean-k-mooney: jkulik: fwiw, this is not a new meat https://review.opendev.org/c/openstack/nova-specs/+/130005 | |
| 13:08:36 | sean-k-mooney | bauzas: yep i know | |
| 13:08:50 | bauzas | sure, but I provided the existing context | |
| 13:09:02 | sean-k-mooney | there are other specs more recnet then that | |
| 13:09:05 | bauzas | just look at the gerrit comments | |
| 13:09:30 | sean-k-mooney | but ya we have rejected dynmic server groups and adding other affinity policies in the past | |
| 13:10:14 | bauzas | yes and no, this is just the fact that the spec was split https://review.opendev.org/c/openstack/nova-specs/+/139272 and https://review.opendev.org/c/openstack/nova-specs/+/136487 | |
| 13:10:22 | bauzas | look again about the comments | |
| 13:10:44 | bauzas | sean-k-mooney: not for you, but rather jkulik | |
| 13:11:15 | jkulik | bauzas: thanks, will take a look | |
| 13:11:20 | sean-k-mooney | bauzas: ack | |
| 13:13:22 | bauzas | jkulik: there was by then a try to have a new API instead of server groups https://review.opendev.org/c/openstack/nova-specs/+/183837/4/specs/liberty/approved/generic-scheduling-policies.rst | |
| 13:13:54 | sean-k-mooney | bauzas: im not sure how that would help | |
| 13:14:07 | sean-k-mooney | the issue with server groups is adding an instance that violates the policy | |
| 13:14:10 | bauzas | just saying this is a can of worms | |
| 13:14:30 | sean-k-mooney | it is | |
| 13:14:38 | bauzas | sean-k-mooney: the problem with server groups is that if we touch it, it creates more races than the ones it fixes | |
| 13:14:42 | sean-k-mooney | but that is a sperate topic form the orginal thing that jkulik raised | |
| 13:15:00 | bauzas | sean-k-mooney: well, this is all about colocality | |
| 13:15:12 | bauzas | we express this in Nova with server groups | |
| 13:15:23 | sean-k-mooney | well affinity and anti affity | |
| 13:15:27 | sean-k-mooney | with differnt granularity | |
| 13:15:29 | sean-k-mooney | but yes | |
| 13:15:52 | bauzas | but the question remains about the best UX we may have | |
| 13:18:24 | bauzas | anyway, me goes back at bug scrub | |
| 14:29:45 | Uggla | question, from the api, I try to check that a scheduling is impossible. To do that I look at 'No valid host found for unshelve instance' in the log. My test seems to work, but I have to wait before checking the logs. Is there a proper way to do that ? | |
| 14:30:54 | Uggla | bauzas, gibi ^ | |
| 14:33:03 | sean-k-mooney | using notifications | |
| 14:33:15 | sean-k-mooney | but in general we dont tend to use logs in tests | |
| 14:33:25 | sean-k-mooney | we do sometimes but there are often better way to do that | |
| 14:33:45 | Uggla | is _wait_for_action_fail_completion a possible option ? | |
| 14:43:15 | gibi | Uggla: you wait for the server to go to ERROR state then you can check the fault in the server to see if it is a no valid host | |
| 14:43:22 | gibi | give me a sec and I will find an example | |
| 14:45:23 | gibi | Uggla: for example https://github.com/openstack/nova/blob/c53ec4e48884235566962bc934cbf292ad5b67b8/nova/tests/functional/test_servers.py#L4100-L4108 | |
| 14:45:28 | Uggla | gibi, ok probably better that what I have just done using wait_for_assert(). | |
| 15:07:24 | bauzas | Uggla: not sure I understand your question | |
| 15:07:36 | bauzas | you're asking how nova-api could know there is a scheduling error ? | |
| 15:07:53 | Uggla | bauzas, no worries Gibi is helping me right now. | |
| 15:08:06 | bauzas | oh, for testing | |
| 15:08:41 | sean-k-mooney | yep testing | |
| 15:08:46 | sean-k-mooney | presumable functional testing | |
| 15:08:51 | sean-k-mooney | rather then unit | |
| 15:11:24 | gibi | yepp func testing | |
| 15:11:58 | gibi | Uggla just found the limitation of the our nova.tests.functional.integrated_helpers.InstanceHelperMixin._wait_for_instance_action_event assert | |
| 15:12:18 | gibi | it always checks the first action of a given type from the list of instance actions | |
| 15:12:27 | gibi | and he had two unshelve actions in the test case | |
| 15:12:35 | gibi | and the assert only checked the first | |
| 15:12:43 | gibi | even though the second was in error state | |
| 15:29:27 | bauzas | reminder: nova meeting in 30 mins | |
| 15:31:07 | sean-k-mooney | oh fun | |
| 15:31:16 | sean-k-mooney | i was not aware we had that limitation | |
| 15:40:06 | gibi | me neither, but now Uggla can improve on that :) | |
| 15:42:15 | Uggla | gibi, sean-k-mooney , currently not completely sure but no the code looks ok. It is more the event I'm looking for which is not the good one. | |
| 15:43:38 | gibi | it can be that the listing of the instance actions are not stable so sometimes the code founds the proper unshelve action sometimes not | |
| 15:48:34 | gibi | I mean the sorting is not stable | |
| 16:00:11 | bauzas | #startmeeting nova | |
| 16:00:11 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:00:11 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:00:11 | opendevmeet | Meeting started Tue Jun 28 16:00:11 2022 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:00:15 | bauzas | hello everyone | |
| 16:01:09 | bauzas | mmmm | |
| 16:01:21 | bauzas | heyhoooooooo | |
| 16:02:00 | gibi | o/ | |
| 16:02:19 | bauzas | hah, I hear some sound | |
| 16:02:30 | gibi | crickets ? | |
| 16:02:42 | bauzas | I'm maybe in a cave | |
| 16:03:22 | bauzas | gibi: not sure we have quorum for today's meeting :( | |
| 16:03:23 | elodilles | o/ | |
| 16:03:37 | gibi | sean-k-mooney already gone for today | |
| 16:03:58 | gibi | I guess melwitt is still on PTO | |
| 16:03:59 | bauzas | hah | |
| 16:04:05 | bauzas | yes indeed + artom | |
| 16:04:30 | bauzas | what would you want ? | |
| 16:05:03 | gibi | do we have somebody here for the todays nova meeting to talk about specific things? (if not then we can close this) | |
| 16:05:39 | bauzas | we still have one critical bug | |
| 16:05:41 | elodilles | nothing special news from stable point of view, so - | |
| 16:06:05 | bauzas | I can be the bug baton owner for the next week | |
| 16:06:28 | bauzas | that said, next week we will have a spec review day | |
| 16:06:38 | bauzas | I'll email it | |
| 16:06:49 | bauzas | that's it for me | |
| 16:07:21 | gibi | nothing from me I spent most of the week downstream | |
| 16:07:28 | bauzas | #info Next bug baton is still for bauzas | |
| 16:07:37 | bauzas | #info One Critical bug | |
| 16:07:46 | bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 8 new untriaged bugs (-4 since the last meeting) | |
| 16:07:51 | bauzas | #link https://storyboard.openstack.org/#!/project/openstack/placement 27 open stories (+1 since the last meeting) in Storyboard for Placement | |
| 16:07:54 | bauzas | #link https://storyboard.openstack.org/#!/story/2010108 new Placement bug | |
| 16:08:01 | bauzas | but I'll tell it again next week | |
| 16:08:17 | bauzas | #info Spec review day on July 5th | |
| 16:08:32 | bauzas | that's basically it | |
| 16:08:40 | gibi | I guess in the critical bug we keep the job non-votig while waiting for the fix to be released in centos stream 9 | |