Support existing secret for external DB

[cest-pas-faux]

Hi,

This PR adds the ability to specify an existing secret for all the DB configurations (host, port, user, password, coreDatabase).

Tests done with this updated chart :

• Reference an existing secret and setting existingSecret.enabled: true
• Hardcode the connection configuration values under external and set existingSecret.enabled: false

Both tests are successful, pull/push images OK.

[MinerYang]

Hi @cest-pas-faux ,

I don't think these settings expect password need to be mounted as secret, configmap is enough for them.
And it will better align with our other values conventions

Best,
Miner

[cest-pas-faux]

Hi @MinerYang, thanks for this review

The password stored as secret is the current behavior and has not been introduced by me, see templates below :

• https://github.com/goharbor/harbor-helm/blob/main/templates/core/core-dpl.yaml#L130
• https://github.com/goharbor/harbor-helm/blob/main/templates/database/database-secret.yaml
• https://github.com/goharbor/harbor-helm/blob/main/templates/core/core-secret.yaml#L25

I didn't want to create a breaking change by removing this secret which is shared by different components.
How to you want me to proceed ?

[cest-pas-faux]

Hi @MinerYang , any updates on this ?

[github-actions]

This PR is being marked stale due to a period of inactivty. If this PR is still relevant, please comment or remove the stale label. Otherwise, this PR will close in 30 days.

[cest-pas-faux]

Hi @MinerYang , just a heads up :)

[cest-pas-faux]

/remove-lifecycle stale

[github-actions]

This PR is being marked stale due to a period of inactivty. If this PR is still relevant, please comment or remove the stale label. Otherwise, this PR will close in 30 days.

[cest-pas-faux]

/remove-lifecycle stale

[cest-pas-faux]

Hi @MinerYang , did you have any time to look into this PR ?

[github-actions]

This PR is being marked stale due to a period of inactivty. If this PR is still relevant, please comment or remove the stale label. Otherwise, this PR will close in 30 days.

[cest-pas-faux]

@MinerYang , how should we proceed ?

[github-actions]

This PR is being marked stale due to a period of inactivty. If this PR is still relevant, please comment or remove the stale label. Otherwise, this PR will close in 30 days.

[cest-pas-faux]

Hi @MinerYang , this feature is still needed.

[github-actions]

This PR is being marked stale due to a period of inactivty. If this PR is still relevant, please comment or remove the stale label. Otherwise, this PR will close in 30 days.

[cest-pas-faux]

Still needed

[github-actions]

This PR is being marked stale due to a period of inactivty. If this PR is still relevant, please comment or remove the stale label. Otherwise, this PR will close in 30 days.

[cest-pas-faux]

Still needed

[JefeDavis]

@MinerYang I believe what @cest-pas-faux is trying to accomplish is support a use-case like cloudnative-pg, which generates a secret with all needed information to connect to the database upon creation, this is a pretty popular way of provisioning databases in kubernetes and should be supported by harbor.

@cest-pas-faux it may be easier to get this approved and merged if you remove the breaking change here. people may be using the existingSecret value which currently takes a string, you should be able to check to see if the value is a string or a map and revert to the old logic if it is a string

[cest-pas-faux]

Hi, @JefeDavis , thanks for your interest and it could be what's blocking us to move forward (even if if think implementing a detection of string/map would be very dirty instead of just having a small breaking change).

However, I'm chasing up since more than a year with no answers, it's hard to guess what's blocking us here, and the only answer I got is unrelated.

@MinerYang , let us know if you want this PR closed or this is something you're willing to implement, and if yes, how ?

[ildoc]

interested! I'm waiting to this feature to be merged to deploy harbor with external-secrets!

thank you @cest-pas-faux for the good work, let's hope @MinerYang will merge this pr as soon as possible

[fredericrous]

thanks for the PR. imo this change is definitely needed to use the harbor helm chart in production.
I thumbed up the first message of this PR and issue #2196 I invite you who read this message and is not a maintainer to do the same.
Note for homelab users: you might already be using gitea. Recent versions of gitea come with a docker registry already