Manage the Portable Resource Classes at a higher level in a single namespace #922
Description
What problem are you facing?
From: Dylan Griffith
https://gitlab.com/groups/gitlab-org/-/epics/1866#note_223600767
@tkuah and I were discussing this just in time stuff the other day and I'm curious to know if it's necessary to create these "Crossplane policy yamls" in each namespace.
I was curious to know if Crossplane has some way to manage these at a higher level in a single namespace and still allow all namespaces to create the crossplane resource claims. It would be preferable if we didn't need to update the GitLab backend code to add all of these resources to every namespace we create.
I would also think that the downside of installing all of these policies into every namespace is that it's tricky to keep them updated.
Background
The bulk of the managed service config (resource class templates, provider config, etc.) is typically stored in a single infra namespace (per environment e.g. aws-infra-dev) and used by multiple app project namespaces.
The policy yamls (portable resource classes) are very simple mappings that make classes-of-service available for use in an app project namespace, and to configure default classes-of-service.
apiVersion: database.crossplane.io/v1alpha1
kind: MySQLInstanceClass
metadata:
name: mysql-standard
namespace: app-project1-dev
labels:
default: true
classRef:
kind: RDSInstanceClass
apiVersion: database.aws.crossplane.io/v1alpha1
name: rds-mysql-standard
namespace: aws-infra-devIn an AWS environment offering multiple classes of service, the following Kubernetes objects would result:
namespaces
└── aws-infra-dev
└── provider # AWS provider configuration
└── provider-creds # AWS provider account credentials
└── rds-mysql-standard # RDS-specific class, non-portable config
└── rds-mysql-replicated # RDS-specific class, non-portable config
└── rds-postgres-standard # RDS-specific class, non-portable config
└── rds-postgres-replicated # RDS-specific class, non-portable config
└── app-project1-dev
└── mysql-standard # portable MySQL class of service
└── mysql-replicated # portable MySQL class of service
└── postgres-standard # portable PostgreSQL class of service
└── postgres-ha # portable PostgreSQL class of service
└── mysql-claim # portable MySQL claim for mysql-standard class of service
└── mysql-claim-secret # generated secret to access database
└── wordpress-deployment # standard Kubernetes deployment
└── wordpress-service # standard Kubernetes service
└── app-project2-dev
└── mysql-standard # portable MySQL class of service
└── mysql-replicated # portable MySQL class of service
└── ...
└── app-project3-dev
└── mysql-standard # portable MySQL class of service
└── mysql-replicated # portable MySQL class of service
└── ...
How could Crossplane help solve your problem?
Manage the Portable Resource Classes at a higher level in a single namespace and still allow all namespaces to create the Crossplane resource claims.
Option A:
Perhaps introducing a claim resolver that points to the portable classes in an alternate namespace.
namespaces
└── aws-infra-dev
└── provider # AWS provider configuration
└── provider-creds # AWS provider account credentials
└── rds-mysql-standard # RDS-specific class, non-portable config
└── rds-mysql-replicated # RDS-specific class, non-portable config
└── rds-postgres-standard # RDS-specific class, non-portable config
└── rds-postgres-replicated # RDS-specific class, non-portable config
└── mysql-standard # portable MySQL class of service
└── mysql-replicated # portable MySQL class of service
└── postgres-standard # portable PostgreSQL class of service
└── postgres-ha # portable PostgreSQL class of service
└── app-project1-dev
└── claim-resolver # points to aws-infra-dev portable classes
└── mysql-claim # portable MySQL claim for mysql-standard class of service
└── mysql-claim-secret # generated secret to access database
└── wordpress-deployment # standard Kubernetes deployment
└── wordpress-service # standard Kubernetes service
└── app-project2-dev
└── claim-resolver # points to aws-infra-dev portable classes
└── app-project3-dev
└── claim-resolver # points to aws-infra-dev portable classes
where claim resolver could be something like:
apiVersion: core.crossplane.io/v1alpha1
kind: PortableClaimResolver
metadata:
name: claim-resolver
namespace: app-project1-dev
classRef:
namespace: aws-infra-devOption B:
Alternatively, Crossplane could add claim.spec.classRef.namespace so claims could target portable classes in alternate namespaces
apiVersion: database.crossplane.io/v1alpha2
kind: MySQLInstance
metadata:
name: mysql-claim
namespace: app-project1-dev
spec:
classRef:
name: mysql-standard
namespace: aws-infra-dev
writeConnectionSecretToRef:
name: mysql-claim-secret
engineVersion: "5.6"