The first scenario I proposed in T290536 goes as follows:

• One cluster for first deploy/debug purposes (kube-mwdebug)
• One cluster to serve internal requests to the API (and possibly to wiki pages) (kube-api-internal)
• One cluster to serve public API traffic (kube-api-external)
• One cluster to serve the website, both mobile and desktop (kube-wikis)
• One cluster for jobrunning (kube-jobrunner)
• One cluster for videoscaling (if we can't move it to shellbox)

We could then split these clusters further between group0/group1/group2 wikis, or across database sections, but that would probably be done with a logical split at the kubernetes level (with say an ingress, or announcing services IPs) and not at an LVS level and represents a second layer of complication that we shouldn't get into right now.

In T291918#7386927, @Joe wrote:

The first scenario I proposed in T290536 goes as follows:

• One cluster for first deploy/debug purposes (kube-mwdebug)
• One cluster to serve internal requests to the API (and possibly to wiki pages) (kube-api-internal)
• One cluster to serve public API traffic (kube-api-external)
• One cluster to serve the website, both mobile and desktop (kube-wikis)
• One cluster for jobrunning (kube-jobrunner)
• One cluster for videoscaling (if we can't move it to shellbox)

We could then split these clusters further between group0/group1/group2 wikis, or across database sections, but that would probably be done with a logical split at the kubernetes level (with say an ingress, or announcing services IPs) and not at an LVS level and represents a second layer of complication that we shouldn't get into right now.

I think this is a sensible separation, we have the flexibility to make adjustments as things progress.

Naming things is hard though, I do not agree with the kube prefix, in the future after baremetal mediawiki servers are gone, it will be an prefix that does not mean much. Moreover, we probably want the discovery URLs to derive from the name of the services. I would propose:

• mw-debug
• mw-api-int
• mw-api-ext
• mw-app (we have been calling them app for years, we know it mostly means our real user traffic)
• mw-jobrunner
• mw-videoscaling

In T291918#7387656, @jijiki wrote:

Naming things is hard though, I do not agree with the kube prefix, in the future after baremetal mediawiki servers are gone, it will be an prefix that does not mean much. Moreover, we probably want the discovery URLs to derive from the name of the services. I would propose:

The kube- prefix is noly needed now; it will not be needed once we've moved everything to kubernetes as we will be able to remove the conditionals from mediawiki-config that depend on the servergroup.
Of course, the servergroup is just a label that has a specific use, we can mostly ignore it.

I forgot to add: we probably also want to migrate wikitech early in the process. It will need us to add php-ldap to our debug image, but it should allow us to dogfood the new installation early *and* to normalize as much as possible wikitech in the process.

In T291918#7387775, @Joe wrote:

In T291918#7387656, @jijiki wrote:

Naming things is hard though, I do not agree with the kube prefix, in the future after baremetal mediawiki servers are gone, it will be an prefix that does not mean much. Moreover, we probably want the discovery URLs to derive from the name of the services. I would propose:

The kube- prefix is noly needed now; it will not be needed once we've moved everything to kubernetes as we will be able to remove the conditionals from mediawiki-config that depend on the servergroup.
Of course, the servergroup is just a label that has a specific use, we can mostly ignore it.

Understood, I believe though, using the 'finalised' naming scheme from the get-go, will save us some cleaning up in the future.

In T291918#7387778, @Joe wrote:

I forgot to add: we probably also want to migrate wikitech early in the process. It will need us to add php-ldap to our debug image, but it should allow us to dogfood the new installation early *and* to normalize as much as possible wikitech in the process.

We can have a go soon enough even using the mwdebug service we have now, or create a new one for it.

In T291918#7387775, @Joe wrote:

In T291918#7387656, @jijiki wrote:

Naming things is hard though, I do not agree with the kube prefix, in the future after baremetal mediawiki servers are gone, it will be an prefix that does not mean much. Moreover, we probably want the discovery URLs to derive from the name of the services. I would propose:

The kube- prefix is noly needed now; it will not be needed once we've moved everything to kubernetes as we will be able to remove the conditionals from mediawiki-config that depend on the servergroup.
Of course, the servergroup is just a label that has a specific use, we can mostly ignore it.

Just to clarify:

the kube- prefix is only needed for the SERVERGROUP env variable we pass to mediawiki. We can use kube- there, and mw- for the namespaces.

In T291918#7387656, @jijiki wrote:

Naming things is hard though, I do not agree with the kube prefix, in the future after baremetal mediawiki servers are gone, it will be an prefix that does not mean much. Moreover, we probably want the discovery URLs to derive from the name of the services. I would propose:

• mw-debug
• mw-api-int
• mw-api-ext
• mw-app (we have been calling them app for years, we know it mostly means our real user traffic)
• mw-jobrunner
• mw-videoscaling

I agree with most of these with regard to naming, except mw-app. People who have been here long may know it's the real user traffic, but it's not clear if you do not already have that background info. A migration like this is an occasion to revisit "tradition" and fix meaning drift.
A few suggestions:

• mw-main <= Frontrunner for me
• mw-live
• mw-web

mw-main is probably the least misleading one, yes. I would like mw-web more, but it's going to mislead a lot of people into thinking it's just requests to wiki pages, while I'd like to also add api requests coming from browsers (to a certain approximation).

This may be a stupid question but why would the api requests coming from browsers not go to the endpoint mapped to mw-api-ext?

In T291918#8328103, @Clement_Goubert wrote:

In T291918#7387656, @jijiki wrote:

Naming things is hard though, I do not agree with the kube prefix, in the future after baremetal mediawiki servers are gone, it will be an prefix that does not mean much. Moreover, we probably want the discovery URLs to derive from the name of the services. I would propose:

• mw-debug
• mw-api-int
• mw-api-ext
• mw-app (we have been calling them app for years, we know it mostly means our real user traffic)
• mw-jobrunner
• mw-videoscaling

I agree with most of these with regard to naming, except mw-app. People who have been here long may know it's the real user traffic, but it's not clear if you do not already have that background info. A migration like this is an occasion to revisit "tradition" and fix meaning drift.
A few suggestions:

• mw-main <= Frontrunner for me
• mw-live
• mw-web

Given that main is kind of generic, I think I would vote for mw-web.

In T291918#8328319, @Clement_Goubert wrote:

This may be a stupid question but why would the api requests coming from browsers not go to the endpoint mapped to mw-api-ext?

Because the api traffic from actual users (which means, if we refer to the mediawiki api and coming from outside of production, browsers and the mobile apps) is what we want to preserve. In moments of high pressure, we could decide to dedicate more resources to that pool rather than to the api pool for bots, who can safely retry later or wait in queue for 10 seconds if needed.

Given both of your answers, I think mw-web is actually the better choice, barring calling it mw-real-users which is kind of weird.
The API calls from browsers still fall under the "web-browsing" umbrella from a functional and grouping standpoint so the moniker still makes sense, and it is more descriptive of what the cluster actually does than the generic mw-main.
Thoughts?

Since there seems to be consensus on everything but mw-{app,main,web}, I'll consider these other service names as valid going forward unless told otherwise:

• mw-debug
• mw-api-int
• mw-api-ext
• mw-jobrunner
• mw-videoscaling

NB: This will require switching the current mwdebug service to the new mw-debug service name, with all the configuration changes that entails in the traffic layer, the service discovery and the custom deployment scripts.

Settling on mw-web as there's been no contrary opinion in a week.