[14:42:45] inflatador: if the writes are staying dc-local, you can just point to the same a/a record, it would be dc-local unless depooled [14:43:06] Otherwise, myservice.svc.{eqiad,codfw}.wmnet is what you're looking for [14:43:16] Oh, c.danis already answered that [14:43:26] well that'll teach me not to read the backlog completely [14:52:51] Hey folks! Me and Moritz worked on a new staging stack for maps, that is totally separated from production (db, swift cache, kartotherian/tegola staging pods, etc..). It would be really nice to expose a maps-staging.wikimedia.org endpoint, so that new changes could be easily tested by the community (one example would be https://phabricator.wikimedia.org/T408884). I think that it should be a ok use case, we could preemptively set up a [14:52:51] requestctl rule to limit traffic to avoid abuse. Any thought? [14:55:46] elukey: how do you feel about maps-next.wm.o instead of -staging (which often has a specific but different meaning) [14:56:43] cdanis: totally fine for me :) [14:56:55] aside from that i love it, are you putting it on wikikube? [14:58:10] my idea was to simply use the wikikube staging deployments, sending requests via the staging ingress [14:58:28] ah [14:58:29] because they are already configured with the right details etc.. [14:58:51] it would be convenient to avoid multiple deployments, this is why I was asking [14:59:03] as long as its truly zero-SLA [14:59:13] oh yes that's for sure [14:59:54] the only other thing that community requested in the past was a way to use a staging endpoint for kartographer in beta [15:00:26] not sure if it is still a use cas [15:00:28] *case