Get rid of "registrycreds" suffix from secrets' names about registry-creds HOT 8 CLOSED

I wouldn't expect it to try create a secret in the same namespace as the seed.

I would expect to create a secret with a given name and then have that replicated to all new namespaces.

from registry-creds.

Why do you want that behaviour?

from registry-creds.

To keep the secrets' names consistent across namespaces.
Let me turn around the question: what is the technical reason to add registrycreds suffix to each secret ?

from registry-creds.

I'm open to hearing why this is necessary.

Can you fill out the whole issue template this time?

**Is your feature request related to a problem? Please describe.**
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

**Describe all possible solutions, and which you suggest**
A clear and concise description of what you want to happen.


**Describe alternatives and workarounds that you've considered**
A clear and concise description of any alternative solutions or features you've considered.


**Additional context**
Add any other context or screenshots about the feature request here.

from registry-creds.

I agree here with @przemolb we have a secret called harbor-image-pull-secret and then the secret that appears in each namespace is harbor-image-pull-secret-creds.

I had to end up explaining to the development team why they should be using harbor-image-pull-secret-creds as they found it misleading.

I think the easiest way to do this is for registry-creds to simply bootstrap the other namespaces with the same secret name as the CRD references for consistency.

from registry-creds.

@swade1987 without a prefix, you could not have the image pull secret in the same namespace as the seed.

So let's say you had a seed called registry-creds in default. How are you going to then have the controller manage that namespace? It cannot create the managed secret because it would already exist, in an unmanaged state. I'm open to suggestions.

from registry-creds.

Came here for this exact issue.
When thinking of replicating a secret across namespaces what comes to mind is copy the source everywhere else as is.

In a greenfield environment it would be totally fine to have an enforced suffix, but when you are trying to substitute a brute force (read copy it over on ci or whatever to a new ns) instead, then you can't have that suffix. Having the enforced suffix in this case would require updating a couple hundred manifests to use the different secret name instead of just replacing the old one.

from registry-creds.

/lock: inactive, raise your own issue as a GitHub Sponsor

from registry-creds.