Proper chaining of services and use of k8s namespacing

Design Discussion

Context and Motivation

Currently, we rely on some hardcoded dependencies and links between components across Yaook. The key of that is the link between the operators and services and Keystone. Because Keystone acts as central service discovery unit, this is where everything comes together (or falls apart).

This is all a bit fragile. When multiple keystones are deployed in a kubernetes cluster, we currently have no specified behaviour of what happens. Let alone what happens if multiple keystones are deployed in a single namespace.

Goals of the Discussion

• Decide on how to link multiple (OpenStack or infra) services together to form a cluster in an explicit, rather than implicit way
• Decide how and which services can be linked across Kubernetes namespaces for the purposes of isolation
• Decide whether it should be possible to run multiple independent instances of each operator or whether there should be one operator per service to rule them all in a productive cluster.
• Decide on whether it should be possible to run multiple independent Yaook OpenStack clusters in the same Kubernetes cluster.

Goals of the Project

... and how they relate to the discussion

• Security:

  • Separating different services in different namespaces makes it easier to reason about what each service account can access and modify. Writing RBAC rules becomes easier when things are scoped more narrowly.

• Reliability:

  • By making the relationship between services explicit, it is easier to reason about which service talks to which other service.