[11:06:24] our scaffolding chart generates the `registry: docker-registry.wikimedia.org` value. I was wondering: why not using `docker-registry.discovery.wmnet`? the first one goes to the internet, then ATS to come back to our private network, whereas the latter stays on the private net. I expect that might cause somewhat faster docker pulls. WDYT? [11:11:49] (local tests on a dse-worker host tends to show that pull times are ~ the same, and that the bulk of the time is taken by the layer extraction) [11:24:07] I think the idea was that the charts should generally be usable outside of our infra and we override the registry during deploments (at least that's what we do in wikikube) [11:46:48] Might there also be caching at the ATS level? [12:33:43] not for the docker registry, we don't cache objects in ATS afaik [12:34:00] (aside from cache-upload but it is a special use case) [12:59:21] on wikikube we both override the hostname and we have Dragonfly installed, right? [12:59:59] also we definitely cache non-cache-upload objects in ATS as well [13:00:19] and it will hit Varnish, not ATS [13:00:25] well, really, haproxy :) [13:11:45] cdanis: we do? I thought it would have been too costly, and that by default we pass for things like the registry [13:51:20] klausman just got back from vacation...do you still need https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/1054541/4 and friends reviewed? [14:04:09] yes, but I'll make it a single change to avoid having to bump the chart version 9 times. I am working on its commit msg right now [14:14:01] inflatador: https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/1060452 [14:53:00] cdanis: true re dragonfly. But that also only works on the docker-registry.discovery.wmnet hostname [14:53:15] ack [15:03:15] klausman :eyes [17:36:24] k-lausman +1'd [17:40:26] merci! [17:41:19] de nada