Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: generate postgres user secret with r2dbc uris #3873

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

bullshit
Copy link

@bullshit bullshit commented Mar 18, 2024

Checklist:

  • Have you added an explanation of what your changes do and why you'd like them to be included?
  • Have you updated or added documentation for the change, as applicable?
  • Have you tested your changes on all related environments with successful results, as applicable?
    • Have you added automated tests?

Type of Changes:

  • New feature
  • Bug fix
  • Documentation
  • Testing enhancement
  • Other

What is the current behavior (link to any open issues here)?

The operator generates user secrets. For example if you use a r2dbc based application you cannot reference the jdbc-uri key from the secret.

What is the new behavior (if this is a feature change)?

  • Breaking change (fix or feature that would cause existing functionality to change)

r2dbc-uri keys are added to the secrets starting with r2dbc:postgresql://....

Other Information:

@bullshit
Copy link
Author

Any feedback regarding this PR? Maybe @dsessler7 could approve this change.

@bullshit
Copy link
Author

Is there any reason this contribution is stagnates?

@andrewlecuyer
Copy link
Collaborator

Hi @bullshit, I was actually just reviewing your changes yesterday. And as we continue to see requests for additional flavors/variants of the connection details within the user Secret (such as additional URI variants, e.g. for r2dbc, in addition to different flavors of the various keys within the Secret, e.g. user vs. username, or db vs. database vs. dbname, etc.),
I am currently assessing options that might provide even more flexibility for the many connectivity use-cases/needs we see out in the wild.

So in other words, rather than endlessly polluting the Secret with access keys, URI's, etc. for that many different variants out there, if would be great to provide users with the ability to define (via the PostgresCluster spec) the exact keys, URI's, etc. they need. And right now I have a couple ideas/designs that I would like to think through before adding another yet key to the Secret. E.g. here is a POC for what something like this might looks like:

spec:
  users:
    - name: rhino
      secret:
        credentialMappings:
          user:
          - username
          - uname
          password:
          - pass
          - pwd
          - passwd
          dbname:
          - database
          - databasename
          - db
          host:
          - hostname
          - hostName
          port:
          - pgPort
        customURIs:
        # user has access to "user", "password", "host" & "port" to build/template out
        # any custom URI needed
        - r2dbc: "r2dbc:postgres://$(user):$(password)@$(host):$(port)/$(dbname)

Which as you cam see, would be another way to get you the r2dbc URI you're looking for:

$ kubectl get secret -n postgres-operator hippo-pguser-someone -o yaml
apiVersion: v1
data:
...
  r2dbc: cjJkYmM6Ly9zb21lb25lOkh2OSUzRitfX1d4PWlWSHhSWjY5eVlZM3dWQGhpcHBvLXByaW1hcnkucG9zdGdyZXMtb3BlcmF0b3Iuc3ZjOjU0MzIvc29tZW9uZQ==
...

I welcome any thoughts/feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants