Open jorgemoralespou opened 4 years ago
Argo is another tool that makes frequent use of generateName
.
When I was testing it's hello-world example, I would get the following output when doing a redeploy with kapp
Namespace Name Kind Conds. Age Op Op st. Wait to Rs Ri
tier0 hello-world-* Workflow - - create - reconcile - -
^ hello-world-86gqr Workflow 1/1 t 1m delete - delete ok -
Op: 1 create, 1 delete, 0 update, 0 noop
Wait to: 1 reconcile, 1 delete, 0 noop
Continue? [yN]: y
10:15:37PM: ---- applying 2 changes [0/2 done] ----
10:15:37PM: delete workflow/hello-world-86gqr (argoproj.io/v1alpha1) namespace: tier0
10:15:39PM: create workflow/hello-world-* (argoproj.io/v1alpha1) namespace: tier0
10:15:39PM: ---- waiting on 2 changes [0/2 done] ----
10:15:39PM: error: reconcile workflow/hello-world-* (argoproj.io/v1alpha1) namespace: tier0
kapp: Error: waiting on reconcile workflow/hello-world-* (argoproj.io/v1alpha1) namespace: tier0:
Errored:
Getting resource workflow/hello-world-* (argoproj.io/v1alpha1) namespace: tier0: workflows.argoproj.io "hello-world-*" not found (reason: NotFound)
I managed to suppress the waiting-reconciliation with the following annotation
annotations:
kapp.k14s.io/disable-wait: ""
This caused a new Workflow object to be created...which I guess was the goal?...but I'm not entirely sure if that's what I wanted to do or not.
I just encountered this as while using an idempotent K8s job with kapp
I can think of two potential approaches to solving this problem for K8s jobs
1) kapp
generates the name
based on generateName
2) kapp
's wait uses the name
returned by the API server
Hey folks - following up here after a few years - is this something that we can still fix?
Hi @dprotaso! It seems like a reasonable ask to me, and I think the first option that you suggested (kapp generates the name based on generateName) makes sense as we already have versioned resources that does something similar. I will mark this as accepted but not sure when we will be able to get to it. We can definitely prioritise a review if you (or someone else) would like to contribute a PR.
Sometimes there's some tools that take advantage of resources defined with
genereteName
instead ofname
in the resource definition, mostly so that a new instance is created every time the resource is applied/created to the cluster. kubectl does require you to use create instead of apply for this type of resources as otherwise it will give an error.In my use case, I'm deploying programmatically a Tekton PipelineRun, and my expected behavior is that everytime that I use
kapp deploy
a new instance is created but the previous are kept under kapp control.After discussing with @cppforlife in the K8s slack, he gave me a workaround which works (after applying a manual fix to remove line https://github.com/k14s/kapp/blob/4db982f52b04bebf30d366f3d9d3f914ef383516/pkg/kapp/diff/template_resource.go#L154 in a local fork). The workaround is to:
With this, what you get is the same behavior as when using generateName but requires you to make a change in your resource definition and also makes the generatedName kapp specific. Although not ideal, it works ok for many (including me).
This issue is to consider whether adding support out of the box to resources defined with generateName make sense and what would be the best implementation.