| 16 Apr 2024 |
 dkliban | it's not very helpful quba42 .... but in the scenario we were talking about, the problem only occurs the second time you sync a repo | 14:42:16 |
| dkliban | but i guess it could also happen when the content is already present in another repository | 14:43:35 |
 ggainey | aye | 14:43:48 |
 quba42 | I can certainly start a thread, what I take away from the initial reaction here is that I am definitely not alone in wondering about how to approach performance. | 14:43:58 |
| ggainey | second sync of those Artifacts | 14:44:03 |
| ggainey | perf-analysis is an art, and everybody should be able to paint at least a little bit :) | 14:44:23 |
| dkliban | quba42: yeah .. you are not a lone and it would be good to have a thread for us to gather ideas | 14:44:23 |
| quba42 | Maybe one more thought: | 14:44:35 |
| quba42 | Not sure if I was clear. | 14:44:40 |
| quba42 | I am not even tying this to any concrete problem along the lines of "this type of sync is way to slow", but just wondering, ok, we have a standard sync, it performs reasonably well, but "could it be better?" | 14:45:39 |
| ggainey | yup - and all of this still applies (well, maybe not the "we ran pgres out of memory" bit) | 14:46:07 |
| quba42 | Ok, I will open that thread. | 14:47:00 |
| dkliban | thank you! | 14:47:03 |
| ggainey | general "could it be better" things for django include "don't assume you can grab all the entities in one giant chunk" and "decide if you can limit querysets to only and exactly the fields you really need for a given flow" | 14:47:04 |
| dkliban | let's take a look at our untriaged issues https://github.com/pulp/pulpcore/issues?q=is%3Aopen+is%3Aissue+label%3ATriage-Needed | 14:47:19 |
| dkliban | the first issue is https://github.com/pulp/pulpcore/issues/5239 | 14:47:31 |
| dkliban | i don't know that we can do anything better for the user | 14:48:13 |
| ggainey | I'm assuming this is a 500 from API? if the error-body has the stacktrace, might be something one could do at the pod-level? | 14:49:30 |
| dkliban | the screenshot is teh content app | 14:49:46 |
| ggainey | ah, I see it now | 14:50:02 |
| ggainey | hm. this might be one more thing around "the content-app needs a redesign to make it possible for the installation to customize result-templates" | 14:51:02 |
| ggainey | like, the app knows the stacktrace it got, it's possible to render that | 14:51:33 |
| dkliban | ok ... so what do we want to do? | 14:54:34 |
| dkliban | i want to close it | 14:54:52 |
 lmjachky | close it; we do not have UI and the traceback should not be visible to regular users | 14:58:20 |
| lmjachky | "and the logs in the operator pod are just python stack traces" really? | 14:58:57 |
| dkliban | lol | 14:59:58 |
| dkliban | next issue https://github.com/pulp/pulpcore/issues/5241 | 15:00:05 |
| dkliban | this looks like a pretty useful feature | 15:00:28 |
| dkliban | let's accept | 15:01:34 |
