| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-09-11 | |||
| 09:16:46 | sean-k-mooney | bauzas: we have see this form operators reporting that its faster | |
| 09:16:53 | bauzas | and none of them said that the filters were outperfomed | |
| 09:17:10 | bauzas | the problem was with the DB | |
| 09:17:13 | sean-k-mooney | i acutlly tought cern said it did | |
| 09:17:13 | bauzas | not the filters | |
| 09:17:20 | sean-k-mooney | i guess it woudl only help | |
| 09:17:35 | sean-k-mooney | as you said if we dont return the 1000 limit on allocitons | |
| 09:17:47 | sean-k-mooney | e.g. if it reduces the set below that | |
| 09:17:56 | bauzas | no, the problem is that NOBODY thought about the performance for getting more than 1000 candidates | |
| 09:18:04 | bauzas | I mean the API performance | |
| 09:18:17 | bauzas | so we said, "ok let's limit to 1000 candidates" | |
| 09:18:39 | bauzas | and then we said "oh but then shit, we won't then verify all the candidates" | |
| 09:18:53 | bauzas | and then that's why we started using prefilters | |
| 09:19:02 | sean-k-mooney | ya i know that i was there | |
| 09:19:14 | sean-k-mooney | and NOBODY is a strech | |
| 09:19:39 | bauzas | if the Placement API was able to provide *all* candidates, the performance in between checking all of them with a filter, or instead querying the Placement *before* wouldn't be differnet | |
| 09:19:40 | sean-k-mooney | we did discuss the subseting problem before we started using placment | |
| 09:20:02 | sean-k-mooney | bauzas: the different is the number of candiates pass to the schduler | |
| 09:20:17 | bauzas | meh, the ship has sailed either way | |
| 09:20:29 | sean-k-mooney | if we have 1000 nodes in 2 az of 500 | |
| 09:20:36 | bauzas | again, not a problem | |
| 09:20:38 | sean-k-mooney | the az prefilter will limit the repsoce to at most 500 | |
| 09:21:05 | sean-k-mooney | without it all 1000 nodes asumming all other thing are equall would pass to the scudler | |
| 09:21:28 | sean-k-mooney | and the az filter would have to filter the 500 nodes then | |
| 09:21:35 | sean-k-mooney | which si where ordering is importnat | |
| 09:21:47 | sean-k-mooney | and why the azfilter come before the expensive ones | |
| 09:22:09 | sean-k-mooney | anyway i can jsut drop the last line that menations performance | |
| 09:23:14 | bauzas | sean-k-mooney: tbc, filters aren't expensive | |
| 09:23:25 | bauzas | even the NUMATopology one, per say | |
| 09:23:42 | bauzas | compared to how long it takes for getting all the candidates | |
| 09:24:21 | sean-k-mooney | that has not been my experince but i also have not seen data for large clouds | |
| 09:24:46 | sean-k-mooney | it really jsut comes down to how many candiate you need to check | |
| 09:24:55 | sean-k-mooney | well hosts | |
| 09:25:33 | sean-k-mooney | bauzas: by the way we both also agree that schduling is not the slow part fo booting a vm | |
| 09:25:48 | sean-k-mooney | bauzas: but what your really arguing is the previous docs were wrong | |
| 09:26:01 | bauzas | sean-k-mooney: don't get me wrong | |
| 09:26:15 | bauzas | placement is better for large clouds compared to what we had in the past | |
| 09:26:18 | sean-k-mooney | when they said enabling the prefilter would improve performance | |
| 09:27:08 | bauzas | sean-k-mooney: true, I'm just saying 'folks, don't trust everything written or said by someone you care" | |
| 09:27:29 | bauzas | and rather experiment yourselves or at least look at more than a single person | |
| 09:28:03 | sean-k-mooney | so tl;dr drop the last line and we good ? | |
| 09:28:10 | bauzas | I'd say so | |
| 09:28:13 | sean-k-mooney | cool | |
| 09:28:46 | sean-k-mooney | that also means i dont need to figure out how to adress gibis comment if i jsut delete the line :) | |
| 09:56:19 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/rocky: libvirt: Handle VIR_ERR_DEVICE_MISSING when detaching devices https://review.opendev.org/742417 | |
| 09:56:20 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/rocky: libvirt: Do not reference VIR_ERR_DEVICE_MISSING when libvirt is < v4.1.0 https://review.opendev.org/747361 | |
| 10:17:30 | lyarwood | random question for the channel but does anyone know if CODEOWNERS has ever been talked about within OpenStack? https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners & https://docs.gitlab.com/ee/user/project/code_owners.html | |
| 10:18:17 | lyarwood | I appreciate this is platform specific without us writing automation around it for opendev but it seems like a nice codeified way of keeping https://wiki.openstack.org/wiki/Nova#People up to date | |
| 10:21:47 | sean-k-mooney | not familar with it | |
| 10:22:09 | sean-k-mooney | but it does not really aligh with how we work since we dont have subsystem maintianers | |
| 10:22:16 | sean-k-mooney | if we did then yes | |
| 10:22:51 | sean-k-mooney | lyarwood: i didnt even know that existed | |
| 10:22:58 | lyarwood | we've listed contacts for areas of the code on the wiki for years now | |
| 10:23:09 | lyarwood | yeah I only just heard about it tbh | |
| 10:23:11 | sean-k-mooney | right but that is not what i tought we used | |
| 10:23:25 | sean-k-mooney | i tought we only had https://wiki.openstack.org/wiki/Nova/BugTriage | |
| 10:23:31 | sean-k-mooney | the tag owners | |
| 10:23:42 | lyarwood | we don't use CODEOWNERS for that, I'm suggesting we do so we can keep this in the actual git tree vs a random wiki page | |
| 10:24:08 | sean-k-mooney | right but i dont think the peopel section makes sense | |
| 10:24:13 | sean-k-mooney | the tags might | |
| 10:24:35 | sean-k-mooney | the bullets in the people section dont correspond to files or subsystmes | |
| 10:26:39 | lyarwood | ah sorry I was thinking about Developer Contacts | |
| 10:27:02 | lyarwood | but anyway I'd rather this lived in tree as there appears to be tooling to do quick lookups locally | |
| 10:27:10 | lyarwood | without relying on a given platform | |
| 10:27:47 | sean-k-mooney | also did not know that existed | |
| 10:28:11 | sean-k-mooney | but ya i can see it just bing a file in the git repo i guess | |
| 10:28:35 | sean-k-mooney | just a simiple yaml file or rst in the docs under the contibutors section | |
| 10:29:06 | sean-k-mooney | lyarwood: i wonder how much traffic if any the wiki gets | |
| 10:29:27 | sean-k-mooney | i have very very rearly checked any of the wikis since we started using specs | |
| 10:30:00 | sean-k-mooney | i do if google brings be there but that is very rare | |
| 10:30:40 | lyarwood | sean-k-mooney: yeah we could also render it somehow in the docs I'm sure | |
| 10:31:01 | lyarwood | sean-k-mooney: I also hardly ever go there, just had a patch against stable that needed to go to master first so went looking for docs | |
| 10:31:15 | lyarwood | sean-k-mooney: found the wiki pages and recalled reading about CODEOWNERS somewhere the other day | |
| 10:31:21 | sean-k-mooney | and the wiki was the only place? | |
| 10:31:56 | sean-k-mooney | i dont know if we even mention the wiki in the contibutors guide anymore | |
| 10:32:03 | lyarwood | sean-k-mooney: no I've linked to the contrib guide | |
| 10:32:18 | lyarwood | sean-k-mooney: it links to the wiki in places iirc | |
| 10:32:23 | sean-k-mooney | the only wiki page i check semi regularly is https://wiki.openstack.org/wiki/Meetings/Nova | |
| 10:34:15 | brinzhang_ | gibi: hi | |
| 10:34:36 | brinzhang_ | gibi: https://review.opendev.org/#/c/729563/13/nova/tests/unit/compute/test_api.py@7685 here, what did your mean? | |
| 10:36:48 | gibi | brinzhang_: I don't expect any change in your patch due to that comment | |
| 10:37:13 | gibi | it is just a note why we are collecting arqs for shelve even if during shelve we dont use them | |
| 10:37:18 | brinzhang_ | gibi: ack, thanks, I misunderstand that words | |
| 10:37:29 | brinzhang_ | yes | |
| 10:37:31 | gibi | sorry, I could have been clearer in my words | |
| 10:37:55 | brinzhang_ | np, I will update later | |
| 10:39:05 | gibi | thanks | |
| 10:39:07 | brinzhang_ | gibi: https://review.opendev.org/#/c/729563/13/nova/tests/fixtures.py@2601 this can't change to arq_host_rp_list = CyborgFixture.bindings_by_instance.get(instance_uuid, []) | |
| 10:39:09 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/queens: [placement] Add status and links fields to version document at / https://review.opendev.org/751239 | |
| 10:39:33 | brinzhang_ | in Line2601, if the arq_host_rp_list==[], that will be an error | |
| 10:39:42 | brinzhang_ | so I will keep this not change yet | |
| 10:40:02 | brinzhang_ | if arq_host_rp_list ==[], return [] | |
| 10:41:47 | openstackgerrit | Hemanth Nakkina proposed openstack/nova master: Update pci stat pools based on PCI device changes https://review.opendev.org/749175 | |
| 10:42:39 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/pike: [placement] Add status and links fields to version document at / https://review.opendev.org/751240 | |
| 10:42:46 | gibi | brinzhang_: you are right, my mistake I mixed arq_host_rp_list with bound_arq_list | |
| 10:42:52 | brinzhang_ | gibi: https://review.opendev.org/#/c/729563/13/nova/tests/fixtures.py@2557 | |
| 10:42:59 | brinzhang_ | gibi: ack | |
| 10:56:25 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Support old & new versions of svm and vmx traits https://review.opendev.org/660515 | |
| 10:56:37 | lyarwood | ^ kashyap / stephenfin ; fixed up some nits quickly if you can review and ack | |
| 10:56:47 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Follow up for I67504a37b0fe2ae5da3cba2f3122d9d0e18b9481 https://review.opendev.org/750184 | |