Default namespace for packages should be upstream expected namespaces

[jorgemoralespou]

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.

[seemiller]

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 tanzu-certificates namespace and not the expected cert-manager namespace.

[jpmcb]

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:

• if package has a default, expected namespace, use that namespace
• if package has no default namespace, create one with naming convention tce-x

[jorgemoralespou]

We've already run into one case where a package didn't work as expected because it wasn't in its default namespaces.

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.

[jpmcb]

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 cert-manager namespace?

[jessehu]

@jpmcb harbor package doesn't care the cert-manager namespace.

[jorgemoralespou]

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.

[seemiller]

If I recall correctly, this issue was spurred by the cert-manager package having a different namespace (tanzu-certificates) than the default upstream value (cert-manager). I've the latest cert-manager packages (1.3.3, 1.4.4 and 1.5.3) all have cert-manager as the default namespace.

It feels like we just need a documentation update to recommend the default or a tce- tagged namespace. I'll see about doing that for this issue.