Project and namespace naming issue when deploying a service into the same cluster as Kargo

[oscr]

Checklist

• I've searched the issue queue to verify this is not a duplicate feature request.
  * [ ] I've pasted the output of kargo version, if applicable.
  * [ ] I've pasted logs, if applicable.

Proposed Feature

Either:

• Add a Project "display name" which is used in the Kargo UI instead of Project name if it is set.
• Add the option to name the Project namespace.
• Add the option to adopt a namespace with a different name than the Project.

Motivation

When creating a Project Kargo will create a matching namespace with the same name. It is also possible for a project to adopt an existing namespace. However adoption seems to require Project and namespace name to match.

But assume we want to deploy a service into the same cluster as Kargo itself is running in. For example cert-manager. If we call the Project cert-manager then both Kargo and cert-manager will try to create resources in the same namespace. This could be avoided by placing cert-manager in another namespace or e g calling the Project something like cert-manager-project. But it would be nice to just have a cert-manager project i Kargo.

Thank you team for your great work with Kargo!

Suggested Implementation

[remi-gelinas]

+1, I scope namespaces to kargo- for existing services, and it's just UI cruft to have the display name be prefixed as well. I'd love the ability to provide a display name separately.

[antoine-sncf]

+1 in my case, as the infra-provider, the namespace name can be quite long as i need to respect some internal norms + unique keys identifiers:
"abc-dev-prj-12345-myproject1"
This is quite ugly in kargo and i would like to have the project named in Kargo "My Project1 (12345)" (functional tuned name) as the projects themselves don't need the first 3 parts (abc-dev-prj)

In our case we create the namespaces beforehand (and then we use namespace adoption) .

I also believe that the kargo.project should be namespaced (in the kargo namespace) as I think that there is no need to have it cluster scoped (just like argocd applications) but that's an other topic.

[krancour]

I understand that this is bothersome to some users and believe there is some room for discussion.

We have always seen Projects as proxies for namespaces. At one time "projects" were just specially labeled namespaces. We didn't initially have a Project resource type. The (primary, but not only) driver for its introduction was to insert more automation into project (little p) namespace initialization. The matching names were deliberate. You named your Project the same as the namespace you wished to create and initialize. The namespace is what mattered and the Project was a means to an end. Adoption came later to add project initialization to existing namespaces, but didn't undermine the scheme of Project and namespace name matching. You named your Project the same as the namespace you wished to adopt.

There's an elegant simplicity to all that, which in many contexts proves to be very convenient. Recall that not everyone uses the UI. Many users interact with Kargo through its CLI, kubectl, or even GitOps their Kargo projects. If you operate with a resource-oriented view of the world, the fact of metadata.name reliably indicating what project a resource belongs to is a benefit I would not want to part with.

The terms "project" and "namespace" are also used interchangeably throughout the code base. If, for example, a function takes project name as an argument and needs to find all Stages in that project, namespace: project is part of the selection criteria. If we dispense with the project/namespace equivalence, there is an enormous number of selection criteria that need to change as well as function signatures and variable names that would also need to change for clarity. It's not a find/replace. It's a large-scale refactoring by hand.

All this is to say: Out of the proposed approaches, the "display name" suggestion seems most favorable, as maintaining the project/namespace equivalency retains the benefits noted above and avoids the noted disruptions. For consistency with precedent already set elsewhere in Kargo (with Freight), I'd propose calling it "alias" instead.

At the same time, I don't want to pretend that such a feature as Project aliases isn't still quite a bit of work. CLI commands will end up requiring an alternative to the --project flag, like --project-alias. If the UI favors showing the alias over a Project's real name, the real name needs to still be displayed somewhere, just less prominently. Searching projects on the home page probably needs to search for Projects with matching names or aliases. We would probably require new labels, indices, mutating webhooks, etc. I'm only scratching the surface.

So for now, let's say that any movement on this issue first requires a comprehensive proposal, ideally from someone willing to do the work.

I also believe that the kargo.project should be namespaced (in the kargo namespace) as I think that there is no need to have it cluster scoped (just like argocd applications) but that's an other topic.

In its capacity as a proxy for a namespace, Projects should be cluster-scoped, just as namespaces themselves are. Even if a compelling argument could be made to the contrary, it would be a severe breaking change, and for that reason alone, isn't something we could entertain.