Decouple Kubernetes Resource Name and RDBMS Resource Name

[zhekazuev]

What problem are you facing?

Currently, the provider-sql uses the name of the Kubernetes manifest(resource) as the name of the database resource(Role, Database, etc.).

This approach introduces several limitations:

• Database role names cannot include underscores(_) or other characters restricted by Kubernetes naming conventions, but it should be possible because Postgres Naming Conventions.

  SQL identifiers and key words must begin with a letter (a-z, but also letters with diacritical marks and non-Latin letters) or an underscore (_).

• It is not possible to create resources(Role, Database, etc.) with the same name, but with different ProviderConfigs inside (some database instances per cluster scenario or multi-tenancy using Compositions).

To resolve these issues, I propose introducing a separate field within the spec of the Provider Resources to explicitly define the database resource name, as it works in the next providers:

• provider-kubernetes:

  # ref: https://github.com/crossplane-contrib/provider-kubernetes/blob/main/examples/object/object.yaml
  apiVersion: kubernetes.crossplane.io/v1alpha2
  kind: Object
  metadata:
  name: sample-namespace
  spec:
  forProvider:
    manifest:
      apiVersion: v1
      kind: Namespace
      metadata:
        # name in manifest is optional and defaults to Object name
        # name: some-other-name
  ...

• provider-keycloak:

  # ref: https://github.com/crossplane-contrib/provider-keycloak/blob/main/examples/roles.yaml
  apiVersion: role.keycloak.crossplane.io/v1alpha1
  kind: Role
  metadata:
  name: basic-role  # The name of the role in Kubernetes
  spec:
  forProvider:
    name: "basic-role"  # The name of the role in Keycloak
  ...

• provider-openstack:

  # ref: https://github.com/crossplane-contrib/provider-openstack/blob/main/examples-generated/db/userv1.yaml
  apiVersion: db.openstack.crossplane.io/v1alpha1
  kind: UserV1
  metadata:
  name: basic
  spec:
  forProvider:
    name: basic
  ...

• provider-confluent:

  # ref: https://github.com/crossplane-contrib/provider-confluent/blob/main/examples-generated/confluent/kafkatopic.yaml
  apiVersion: confluent.crossplane.io/v1alpha1
  kind: KafkaTopic
  metadata:
  name: orders
  spec:
  forProvider:
    topicName: orders
    ...

• provider-postgresql by Tages:

  # ref: https://github.com/tagesjump/provider-postgresql/blob/main/examples-generated/postgresql/v1alpha1/role.yaml
  apiVersion: postgresql.postgresql.upbound.io/v1alpha1
  kind: Role
  metadata:
  name: my-role
  spec:
  forProvider:
    name: my_role
    ...

This will decouple the Kubernetes resource name from the database resource name, allowing greater flexibility and avoiding naming conflicts.

Example with PostgreSQL Role after that changes:

apiVersion: postgresql.sql.crossplane.io/v1alpha1
kind: Role
metadata:
  name: example-role-k8s  # Kubernetes resource name
spec:
  forProvider:
    name: "example_role_in_db"  # Database role name (optional, defaults to object name if not provided)
    # other variants of field name/paths
    # - roleName
    # - role.name: 
...

Benefits:

• Separation of Concerns: Decouples Kubernetes naming from database naming, providing more flexibility.
• Avoids Naming Conflicts: Allows for the creation of multiple Provider Roles with similar names across different database instances. This is particularly beneficial for scenarios where Crossplane Compositions are used for multi-tenant setups, allowing users to define external resource names directly in the Composition with end-user own naming conventions.
• Compatibility: Ensures backward compatibility by making the name field optional and defaulting to the object name.
• Consistency: Aligns with the naming pattern used in other Crossplane providers, ensuring consistency across different RDBMS types(MySQL, MSSQL, PostgreSQL).

Implementing this change will enhance the usability and flexibility of the provider-sql for various RDBMS types within Crossplane, ensuring it meets user needs more effectively while maintaining compatibility with existing deployments.

How could Crossplane help solve your problem?

Modify the CRD (CustomResourceDefinition):

• Update the CRD for the Provider Resources to include a new name field under spec.forProvider, making it optional and defaulting to the object name if not provided.

Update the Controller Logic:

• Ensure the Crossplane controller logic uses the spec.forProvider.name field when creating roles in the database. If this field is not provided, it should default to the Kubernetes resource name.
• Ensure the Crossplane controller logic uses the spec.forProvider.name field when using ref fields(DatabaseRef, MemberOfRef, etc.)

Tests:

• Test by creating roles using the new structure to verify that roles are correctly created in the database with the specified names.
• Ensure that roles are also correctly created when the name field is not provided, defaulting to the Kubernetes resource name.

[Ben10k]

Hello @zhekazuev Crossplane already supports this functionality. A resources name can be set using the crossplane.io/external-name annotation. For example:

apiVersion: postgresql.sql.crossplane.io/v1alpha1
kind: Role
metadata:
  name: example-role-k8s  # Kubernetes resource name
  annotations: 
    crossplane.io/external-name: custom_name
spec:

More details here: https://docs.crossplane.io/latest/concepts/managed-resources/#naming-external-resources

[zhekazuev]

Hello @zhekazuev

Crossplane already supports this functionality. A resources name can be set using the crossplane.io/external-name annotation.

For example:

apiVersion: postgresql.sql.crossplane.io/v1alpha1

kind: Role

metadata:

  name: example-role-k8s  # Kubernetes resource name

  annotations: 

    crossplane.io/external-name: custom_name

spec:

More details here: https://docs.crossplane.io/latest/concepts/managed-resources/#naming-external-resources

Hello @Ben10k ,

Thanks for the reply, I thought this functionality needs for Claim/Composition resources naming. I will check and close issue on the next week.