Allow writeConnectionSecretToRef to be compatible with SQL community provider

[Keralin]

What problem are you facing?

Using the community provider for SQL can't connect to the cluster created if we reference the secrets generated by writeConnectionSecretToRef to the provider because it will search for password and username instead of master_username and attribute.master_password (as is required in their doc) so it requires so manual action modifying the secret and can't be solved in a GitOps way.

How the secrets should be stored:

apiVersion: v1
kind: Secret
data:
  endpoint: xxxxxx
  password: xxxxxx
  port: xxxxxx
  readerEndpoint: xxxxxx
  username: xxxxxx

How are the secrets stored:

apiVersion: v1
kind: Secret
data:
  endpoint: xxxxxx
  attribute.master_password: xxxxxx
  port: xxxxxx
  readerEndpoint: xxxxxx
  master_username: xxxxxx

How could Official AWS Provider help solve your problem?

Enabling a feature to allow configuring how that secret or parameters should be stored, thus allowing the choice to save the connection with a username and password to be compatible with the community SQL provider like other community providers do.

[turkenf]

Hi @Keralin,

I'm a little skeptical about this issue, changing these fields will cause breaking API changes. It seems more logical to fix this on the provider-sql side.

[ivanfoo]

@turkenf I think the issue here is that an RDS Cluster resource does not publish the connection details using the keys expected by other components https://github.com/crossplane/crossplane-runtime/blob/master/apis/common/v1/resource.go#L25-L44

The SQL Provider just relies on that: https://github.com/crossplane-contrib/provider-sql/blob/afdf5802c7445e6ed42db11b35e1a45d8f2771dd/pkg/clients/postgresql/postgresql.go#L37

I guess it would be possible to keep publishing the current custom fields (like master_password), but to publish also the standard ones. Is that an option?

[chlunde]

Related: #778

[github-actions]

This provider repo does not have enough maintainers to address every issue. Since there has been no activity in the last 90 days it is now marked as stale. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.

[pierluigilenoci]

/fresh

[github-actions]

This provider repo does not have enough maintainers to address every issue. Since there has been no activity in the last 90 days it is now marked as stale. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.