We have started discussing the move behind RESTBase, but I wouldn't classify it as imminent, so let's just move it to text-lb for now.

Note that cxserver uses RESTBase and does not have any references to parsoid

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

Change 266739 had a related patch set uploaded (by BBlack):
cxserver, citoid -> cache_text cluster

https://gerrit.wikimedia.org/r/266739

Change 266740 had a related patch set uploaded (by BBlack):
Text VCL: Add support for citoid cxserver passes

https://gerrit.wikimedia.org/r/266740

Change 266741 had a related patch set uploaded (by BBlack):
cache_parsoid: remove citoid cxserver pass-through

https://gerrit.wikimedia.org/r/266741

In T110478#1965406, @BBlack wrote:

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?

No. It means that cxserver uses restbase. CX extensions uses cxserver.wikimedia.org.

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.

In T110478#1969829, @BBlack wrote:

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:

https://phabricator.wikimedia.org/diffusion/OPUP/browse/production/modules/cxserver/manifests/init.pp;823499e7f52eb8ab57f58869ed2c630f7a5e4b2d$21

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 ....

In T110478#1969870, @BBlack wrote:

@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 ....

Ah, as in using the REST API entrypoint which is proxied by RESTBase instead of the cxserver service entrypoint. I think @mobrovac already answered on that with

In T110478#1580668, @mobrovac wrote:

We have started discussing the move behind RESTBase, but I wouldn't classify it as imminent, so let's just move it to text-lb for now.

back in August 2015. I am not sure what the situation is right though.

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.

@GWicke no need for the stopgap, we'll just keep doing traffic pass-through of cxserver.wikimedia.org for now (but via cache_text), until it's all resolved at some later point.

@BBlack: Okay, thanks!

Change 266740 merged by BBlack:
Text VCL: Add support for citoid cxserver passes

https://gerrit.wikimedia.org/r/266740

Change 266799 had a related patch set uploaded (by BBlack):
Add cxserver/citoid to cache_mobile

https://gerrit.wikimedia.org/r/266799

Change 266799 merged by BBlack:
Add cxserver/citoid to cache_mobile

https://gerrit.wikimedia.org/r/266799

Change 266739 merged by BBlack:
cxserver, citoid -> cache_text cluster

https://gerrit.wikimedia.org/r/266739

Change 266741 merged by BBlack:
cache_parsoid: remove citoid cxserver pass-through

https://gerrit.wikimedia.org/r/266741