The service itself is still in active use, but the parsoidcache configuration is a trivial pass-through on all traffic. If a natural move to restbase's text-lb-based entrypoint is imminent we can wait on that. Otherwise, we can move the hostname and pass-logic out to the text-cluster.
|operations/puppet : production||cache_parsoid: remove citoid+cxserver pass-through|
|operations/dns : master||cxserver, citoid -> cache_text cluster|
|operations/puppet : production||Add cxserver/citoid to cache_mobile|
|operations/puppet : production||Text VCL: Add support for citoid+cxserver passes|
Does that imply that nothing should be using the hostnames cxserver.wikimedia.org and/or cxserver.eqiad.wikimedia.org, which map to the cache_parsoid cluster rather than through restbase?
FYI, I'm still seeing live requests to the cxserver public hostnames on cache_parsoid, e.g.
32 RxURL c /v1/dictionary/recopilaciones/es/es/JsonDict 32 RxHeader c Host: cxserver.wikimedia.org 32 RxHeader c referer: https://es.wikipedia.org/wiki/Special:ContentTranslation?page=Abu+Talib+ibn+Abd+al-Muttalib&from=en&to=es&targettitle=Abu+Talib+ibn+Abd+al-Muttalib
Ok. I was under the impression that as part of some eventual plan, the CX extensions would switch to using public RB URLs (as in https://es.wikipedia.org/api/rest_v1/...) as well? Regardless, we can still move the entrypoint to cache_text in the commits above for now.
Just adding my 2 cents on this, hoping to clarify things a bit, nope from what I know. The current way of using RESTBase is via the internal LVS service. That is evident here:
Note the http://restbase.svc.eqiad.wmnet part.
@akosiaris - we're talking about two different parts of the problem. Regardless of whether/how cxserver's app code uses RB, what I'm talking about is how the CX client-side code accesses the CX API from the public internet. Apparently that is currently still officially via https://cxserver.wikimedia.org/..., as opposed to something like https://es.wikipedia.org/api/rest_v1/... something cxserver-api-specific ....
The last time we talked about moving the CXServer API to RB the issue was that some of those APIs are really not ready to be public. Some are backed by third-party translation services, and we need to limit access to those.
We could easily set up a private / undocumented entry point that proxies to cxserver in RB if that helps to get rid of the parsoid cache sooner, but from a documentation / public API perspective the value of that would be limited. It would be a stop-gap until we can properly define & document the parts of the cxserver API that could / should be more prominently exposed to the general public.