Decolonise language used for describing and explaining Kubermatic components

[almereyda]

There is an ongoing discussion in the computing world, e.g. ¹, about renaming colonial terminology like master to main, or black & white list to deny & allow list. In Kubermatic, we still find bits of "master" terminology and thus with it an implied reference to slavery and other forms of domination. When reading about master clusters, I'm always getting the impression, this discussion has not yet arrived with Kubermatic, why I am opening this thread.

Are there any considerations within the organisation, which deconstruct the postcolonial narrative of masters and shift its results into some more technically sound and precise terminology? main could be a suitable alternative here, or primary. Others are listed on Wikipedia ².

Then this could be changed throughout the git repositories, and also in the documentation.

👩🏾‍⚖️

Also see:

1. https://sfconservancy.org/news/2020/jun/23/gitbranchname/
2. • https://en.wikipedia.org/wiki/Master/slave_(technology)#Possible_replacement_conventions
   • https://de.wikipedia.org/wiki/Master/Slave#Kritik_an_der_Terminologie

[almereyda]

A clearer terminology can also help to avoid misconceptions around the stack, like what we see in about the observability MLA #10727 (comment).

And also for clusters.

• Assuming Kubermatic CE only allows shared primary / seed clusters:
  Clarification about amount of possible seeds with CE docs#1120
  • All clusters with a Kubermatic installation are primary clusters, in case the seed is installed here. (primary MLA + secondary MLA)
    • User clusters are secondary clusters. (secondary MLA derivation)
  • A primary Kubermatic cluster does not need to hold the Seed. (primary MLA)
    • A single secondary Kubermatic Seed cluster may exist. (primary MLA + secondary MLA)
      • Then ternary user clusters appear. (secondary MLA derivation)
• Eventually Kubermatic EE knows higher levels of abstraction.
  • The primary cluster holds the Kubermatic components (primary MLA)
  • The secondary cluster(s) hold(s) the Seed components (primary MLA + secondary MLA)
  • The ternary clusters are user clusters (secondary MLA derivation)

This naming scheme may also aid in reflecting well what is presented in the architecture diagrams.

• Architecture diagram marginalia are mixed/mingled docs#1121
• Architecture page talks about two different seed clusters, but associated diagram shows same name for both docs#1114

What do you think?

[shaase-ctrl]

Hi @almereyda, thank you for the suggestions.

About terminology:
We are aware of the topic and will adapt this in the future. We are not able to change this on short notice, but we are planning in advance to do that. For marketing material (presentations etc.) we already introduced the term root cluster (instead of master) and seed, as this is also quite fitting. In the past we decided against slave cluster (for the seeds), but nobody is perfect.

[almereyda]

I support everything you say, esp. with emphasis on the last relative sentence. Good to hear that as an organisation you are aware of this question, with full understanding of its operational implications and long term migration paths to be taken into account.

And root cluster is also a very suitable name, indeed, carried by a very appealing metaphore leaning towards the seeds.

I think I basically needed a clearer understanding of

• Wondering about the relation of `monitoring`, `logging` and `minio` charts to MLA #10727

and how the different parts relate to each other, why I wanted to try out, if a different naming scheme also helped me to understand the various layers of clusters better.