| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-09-11 | |||
| 08:45:27 | bauzas | but anyway | |
| 08:45:33 | bauzas | in this case, this sounds legit | |
| 08:45:48 | bauzas | sean-k-mooney: if so, I'll review your deprecation patch | |
| 08:46:06 | sean-k-mooney | the point is in anycase to move both operation eventually to the placment query | |
| 08:46:25 | sean-k-mooney | since in that case ordering does not matter | |
| 08:47:01 | sean-k-mooney | at least form teh point of view of the query construction | |
| 08:48:19 | sean-k-mooney | bauzas: ill ping you with the update patch with just the AZfilter deprecation in a few once its ready | |
| 08:48:34 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Spell out 3pp in vmware undeprecation reno https://review.opendev.org/751188 | |
| 08:48:53 | sean-k-mooney | whats 3pp | |
| 08:49:06 | sean-k-mooney | oh hehe | |
| 08:49:13 | sean-k-mooney | third party | |
| 08:49:28 | sean-k-mooney | i see that was bauzas nit | |
| 08:51:39 | bauzas | sean-k-mooney: also, I left a comment on your deprecation patch, having the sheduler being underoptimized is not a performance issue | |
| 08:55:34 | sean-k-mooney | bauzas: thanks that said the orginal doc state that enabling the prefilter improves performance, so when i flip the docs to state its enabled by default now does it not make sense to now also state that reverting to the az filter woudl reduce performance | |
| 08:56:05 | sean-k-mooney | bauzas: i can remove that i just basically inverted the previous statement but if you dont think it adds value ill just drop it | |
| 08:56:25 | sean-k-mooney | bauzas: you were refering to your comment here right https://review.opendev.org/#/c/745605/3/doc/source/admin/availability-zones.rsthttps://review.opendev.org/#/c/745605/3/doc/source/admin/availability-zones.rst | |
| 08:57:54 | sean-k-mooney | the funny thing is that change was orginally just ment to be the az filter | |
| 08:58:39 | sean-k-mooney | i only added the compute filter when i was doing the doc update and was like waith there is a prefilter that "does the same thing" that can go too. i was wrong :( | |
| 09:13:31 | openstackgerrit | Federico Ressi proposed openstack/nova master: Log stack trace when fails launching a defined domain https://review.opendev.org/750652 | |
| 09:13:47 | openstackgerrit | Federico Ressi proposed openstack/nova master: Log stack trace when fails launching a defined domain https://review.opendev.org/750652 | |
| 09:14:58 | bauzas | sean-k-mooney: I know, we have a lot of docs that are wrong by saying "heh, prefilters are better for performance" | |
| 09:15:09 | bauzas | tbc: NO | |
| 09:15:21 | bauzas | a prefilter just allows you to get more candidates | |
| 09:15:53 | sean-k-mooney | bauzas: that is not true | |
| 09:16:13 | bauzas | filters perfomance is not an issue | |
| 09:16:15 | sean-k-mooney | bauzas: if you enable a prefilter and disable a schduler filter the db outperform python | |
| 09:16:25 | bauzas | sean-k-mooney: again, it's wrong | |
| 09:16:26 | sean-k-mooney | bauzas: in general yes | |
| 09:16:41 | bauzas | lots of folks (eg. CERN) looked at the scheduler performance | |
| 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 | |