Skip to content

fix: avoid over-normalizing Kubernetes application ids#898

Open
immanuwell wants to merge 1 commit into
coroot:mainfrom
immanuwell:fix-k8s-app-id-normalization
Open

fix: avoid over-normalizing Kubernetes application ids#898
immanuwell wants to merge 1 commit into
coroot:mainfrom
immanuwell:fix-k8s-app-id-normalization

Conversation

@immanuwell

Copy link
Copy Markdown
Contributor

Fixes a small k8s app-id papercut. Some user-created Jobs and ReplicaSets can look generated, so Coroot could fold them into the wrong parent app. Not great.

Repro before this patch:

  • NewApplicationId(..., ReplicaSet, "catalog-a") becomes Deployment catalog
  • NewApplicationId(..., Job, "db-migration-1") becomes CronJob db-migration

Both names are valid k8s object names, so this can happen in real clusters. The fix only normalizes the generated-looking forms: ReplicaSet name-<10 hex chars> and Job name-<10+ digits>.

Tested: go test ./model

@def

def commented May 26, 2026

Copy link
Copy Markdown
Member

In general, this looks good. Could you please clarify in which scenarios ReplicaSets are created directly without using Deployments?

@immanuwell

Copy link
Copy Markdown
Contributor Author

@def sorry, somehow I missed this comment

  • canary/traffic-splitting setups - tools like Argo Rollouts manage their own ReplicaSets, for example

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants