Change:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): 'job generateName' (also checked via ) Is this a BUG REPORT or FEATURE REQUEST? (choose one): Bug report Kubernetes version (use ): ~ Environment: Cloud provider or hardware configuration: minikube 0.18.0 on Linux Install tools: kubectl What happened: I'm trying to create a Job resource with a auto-generated name: Applying this with kubectl gives: ~ Adding makes the job work, but obviously now with a fixed name. What you expected to happen: A job with the name 'tool-job-SOMETHING' is created, and a pod tool-job-SOMETHING-ELSE is used to execute the job. How to reproduce it (as minimally and precisely as possible):
will verify the existence of the resources before take action. If the resources do not exist, it will firstly create them. If use , the resource name is not yet generated when verify the existence of the resource. I will submit a PR to fix this. Currently, you can use instead of as a workaround.
Do We need to update the documentation of how kubectl should work with generated names as part of fixing this issue ? I'm not sure what the semantics is there, after all you can either generate more names with unique resources OR modify existing resources....?
It is really a little confused when use with . I think there is need to update the documentation.
with you would have clear intention: just create the resource. is a combination of and , it will fallback to create the resource if not found(use namespace and name to query the resource) or it will do 3-rd way patch. So basically I would not hope to change this behavior of , with generate name it's not easy to check the existence, I would suggest use to create the resource, thus you can use to manage the resource in the future.
Thanks for your clarification. I will send a PR to update the documentation.
Yup that was my hope as well; this isn't a bug b/c of the fact that apply doesn't work if you don't have a deterministic way to check. So let's just update docs and then close the issue .
From my point of view: the explanation for 'apply'-vs-'create' makes perfectly sense, and using 'create' in my case is also reasonable. Having documentation pointing to the differences between those, and having just a bit more documentation on the 'generateName' itself - or close to it - would be very much appreciated. I agree that with that explanation it is not a bug in apply. Thank you for the explanation :)
I'm confused about how generateName and name are supposed to be validated. On a v1.11.2 vanilla Kubernetes cluster, a Deployment with generateName works with "kubectl create" but fails with "kubectl apply". On a v1.10.5-gke.3 GKE cluster, the Deployment works with both create and apply. cc
I really have to argue that this resolution is doubly ineffective. First, the documentation does not make it clear that a nameGenerator cannot be used to create jobs via . It took a full day of work to make it here! Second, more importantly, it really disrupts the overall yaml workflow to forbid with nameGenerators. I understand that there is some complexity to handle in the first application, but I think it would be well worth it to ensure that 'apply' is works across all the reasonable use-cases, including creating new Jobs. If this means adding the ability to specify merge strategy in the generateName key, so be it.
I completely agree with here. To me this seems to be a solution that breaks the overall workflow.
any update?

Discussion:
var ( apply_long = templates.LongDesc(i18n.T(` Apply a configuration to a resource by filename or stdin. <del> This resource will be created if it doesn't exist yet. </del> <ins> The resource name must be specified. This resource will be created if it doesn't exist yet. </ins> To use 'apply', always create the resource initially with either 'apply' or 'create --save-config'. JSON and YAML formats are accepted.