You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you create an instance called "harbor", the harbor helm chart drops the "$RELEASENAME-harbor" behaviour for naming, and instead just uses the release name, so resources end up being "harbor-core" instead of "harbor-harbor-core".
Deploying the operator by chart, relevant values.yaml passed to the operator:
I'm not sure this should actually be fixed/worked around by the operator, since the upstream chart is the one causing the behaviour, but it might be unlikely to change upstream as the logic on the name calculation is non-trivial. The upstream chart does offer overrides to that logic there (fullnameOverride, nameOverride), so perhaps it's worth using those to enforce what the operator installs ends up at names that the api_client.go library is expecting it to be.
Kubernetes Server version: v1.24.3+k3s1
The text was updated successfully, but these errors were encountered:
If you create an instance called "harbor", the harbor helm chart drops the "$RELEASENAME-harbor" behaviour for naming, and instead just uses the release name, so resources end up being "harbor-core" instead of "harbor-harbor-core".
Deploying the operator by chart, relevant values.yaml passed to the operator:
I'm not sure this should actually be fixed/worked around by the operator, since the upstream chart is the one causing the behaviour, but it might be unlikely to change upstream as the logic on the name calculation is non-trivial. The upstream chart does offer overrides to that logic there (fullnameOverride, nameOverride), so perhaps it's worth using those to enforce what the operator installs ends up at names that the api_client.go library is expecting it to be.
Kubernetes Server version: v1.24.3+k3s1
The text was updated successfully, but these errors were encountered: