-
Notifications
You must be signed in to change notification settings - Fork 308
Default namespace for packages should be upstream expected namespaces #607
Comments
We've already run into one case where a package didn't work as expected because it wasn't in its default namespaces. The Harbor packages uses cert-manager and it was not able to generate certs because cert-manager was in the |
If we do this, we should also consider making a recommendation to package authors that have no default upstream namespace, like prometheus. Since prometheus doesn't provide any kind of upstream manifest, I believe the observability team sets it themselves. So it may be worth recommending some kind of namespacing convention in a design doc like:
|
To me, this surfaces a design problem in harbor. It shouldn't need to know the namespace, and if was critical, it should be configurable. |
Also ref #642 I agree with @jorgemoralespou. I think this is a problem where harbor expects cert-manager to be deployed in a way that is technically configurable. Cert-manager is typically deployed via helm and supports being deployed into different namespaces. So, in a helm install, who does harbor expect to only reference the |
@jpmcb harbor package doesn't care the cert-manager namespace. |
HIghlighting that cert-manager being in tanzu-certificates namespace by default is weird. I would love this package to be in cert-manager namespace which is where people expects it. |
If I recall correctly, this issue was spurred by the cert-manager package having a different namespace ( It feels like we just need a documentation update to recommend the default or a |
Feature Request
Make default namespaces for packages that bundle content that is supposed to be installed in a specific namespace to be the expected upstream/default namespace.
A user of TCE packages with knowledge on the technology will by default expect it to be installed in the same destination as if they consume the upstream package. We do still need to support moving into an alternate namespace, as some used might want to concentrate all/some packages into fewer namespaces as they are considered infrastructure components and hence reducing visibility problems for end users.
Why would someone want fewer namespaces for infrastructure components? Mostly because k8s does not provide proper RBAC around the namespaces a user can see, so it's all or none. If there's lots of namespaces in the cluster, users that have only RBAC in a few of them will still see the whole list. This is really cumbersome in UIs and namespace selector experiences.
The text was updated successfully, but these errors were encountered: