We should expose our schema repositories for read-only usage and for browseability.
schema.svc.*.wmnet is deployed internally. We expose this service publicly.
| operations/puppet : production | Set up cache routing for schema.wikimedia.org |
| operations/puppet : production | Fix indentation in discovery.yaml for schema |
| operations/dns : master | Add schema.discovery.wmnet |
| operations/puppet : production | Set up schema.discovery.wmnet |
| operations/dns : master | Add schema.wikimedia.org |
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | Ottomata | T185233 Modern Event Platform (TEC2) | ||
| Open | Ottomata | T201063 Modern Event Platform: Schema Registry | ||
| Open | Ottomata | T206789 Modern Event Platform: Schema Registry: Implementation | ||
| Open | Ottomata | T233630 Public schema.wikimedia.org endpoint for schema.svc |
@Ottomata, I 'd say so. I would ask for review from Traffic or serviceops, but unless it was under the goals of either Traffic or serviceops I don't see how those team would end up driving it.
Change 549105 had a related patch set uploaded (by Ottomata; owner: Ottomata):
[operations/dns@master] Add schema.discovery.wmnet
Change 549106 had a related patch set uploaded (by Ottomata; owner: Ottomata):
[operations/puppet@production] Set up schema.discovery.wmnet
Ok @ema @akosiaris patches for schema.discovery.wmnet ^. Not sure if I need this but I think it would be good for https://github.com/wikimedia/operations-deployment-charts/blob/master/helmfile.d/services/eqiad/eventgate-analytics/values.yaml#L19 and possibly other future uses.
I'll also need to set up the public DNS and routing for schema.wikimedia.org. Should I route to schema.discovery.wmnet?
Change 549173 had a related patch set uploaded (by Ottomata; owner: Ottomata):
[operations/dns@master] Add schema.wikimedia.org
Change 549177 had a related patch set uploaded (by Ottomata; owner: Ottomata):
[operations/puppet@production] Set up cache routing for schema.wikimedia.org
Change 549105 abandoned by Ottomata:
Add schema.discovery.wmnet
Reason:
Don't need discovery, LVS is fine.
@ema, @Joe informs me the that the nginx server serving schema.svc should terminate TLS for the 'encrypt all the things' goal. I have Qs!
Change 549106 merged by Ottomata:
[operations/puppet@production] Set up schema.discovery.wmnet
Change 550493 had a related patch set uploaded (by Ottomata; owner: Ottomata):
[operations/puppet@production] Fix indentation in discovery.yaml for schema
Change 550493 merged by Ottomata:
[operations/puppet@production] Fix indentation in discovery.yaml for schema
Ok, just heard from @ema. To proceed we need to set up an HTTPS internal endpoint for schema.svc. We can do this in a few ways, but as it is right now we'd need an extra LVS entry for the HTTPS svc. If we wait until after end of Q2 for T227432: Replace Varnish backends with ATS on cache text nodes, we can make the main LVS schema.svc entries be HTTPS only, and avoid the extra svc.
Setting up public schema.wikimedia.org isn't strictly blocking anything this quarter, so I'm inclined to wait.
FYI for my own reference, an example of enabling envoyproxy in puppet: https://gerrit.wikimedia.org/r/c/operations/puppet/+/534597