Provide support for resources with generateName

[jorgemoralespou]

Sometimes there's some tools that take advantage of resources defined with genereteName instead of name 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:

• use name instead of generateName
• use kapp.k14s.io/versioned: '' to make kapp create a new version for every resource
• use kapp.k14s.io/nonce: '' to allow kapp to inject a unique ID for every generated resource

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.

[caphrim007]

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.

[caphrim007]

for reference https://argoproj.github.io/argo-workflows/examples/#hello-world

[dprotaso]

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

[dprotaso]

Hey folks - following up here after a few years - is this something that we can still fix?

[praveenrewar]

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.