Change:
cmd.Flags().String("resource-version", "", "If non-empty, the labels update will only succeed if this is the current resource-version for the object. Only valid when specifying a single resource.") usage := "Filename, directory, or URL to a file identifying the resource to update the labels" kubectl.AddJsonFilenameFlag(cmd, &options.Filenames, usage) <ins> cmd.Flags().Bool("dry-run", false, "If true, only print the object that would be sent, without sending it.") </ins> return cmd }

Discussion:
kubectl should support a --dry-run option for every mutation to show what it would do, without actually doing it We might need API changes in order to make this high-fidelity. For instance, if we wanted to know what a pod config would look like after admission control populated defaults, we'd need to execute most of the creation path.
For generator types commands, I think there is a usability argument that the default when a user specifies should be to dry-run (and a user should be allowed to override that with ). I think I'd rather encourage composition of commands (pipe) than every generator command in the system creating objects. We may also want to clarify dry-run against the server vs dry run against the client - there are lots of places where we want to generate locally to a file or an editor or a pipe command before we want to create it. At this point, OpenShift has a few commands that treat -o  as "dry-run" - new-app (complex generator) and export (never expect to send it to the server). We also have a few that are designed to be compositional in a pipe always - process (take a template and turn it into a list of api objects), which never creates the objects for you (you have to pipe to ). I'm somewhat partial to having and support the presence of changing the default of to true, because that's more common and easier than having to set and . The counter argument is that is the preferred action, and is format only - except that by definition --dry-run using the default output format isn't very useful (you created a service named foo and an rc named bar). My gut is that most users once they understand what a particular generator does their default path is always going to be to review the change, and then if they want to create it they can pipe to or just by appending to their existing command. I'm not sure that's a strong enough argument to couple --dry-run and -o, but based on our experience so far it's going to be the "normal" path.
:+1: for this feature. In particular, I would like an ability to validate an object definition separate from actually creating the object. e.g. running at the validation step of my deployment pipeline.
I agree that the validation use case is important. I would distinguish --dry-run from --local.

The former would still entail contacting the server and returning the result of the mutation. The latter would imply that only local information were used.
- I'm planning to add a parameter like 'pretty' or 'labelselector' to API requests. Once the server get this parameter, it will do validation to the resource and check if request can pass admission controls, but return success before write to etcd. I've read the documented about API changing, it lists some principles when changing the api object, but parameters are not mentioned. Is there anything need to be taken special care of when adding a parameter?
We need to be careful about dry-run with admission control... some admission controllers (like quota, specifically), record things to etcd in the process of admitting an object. Also, dry-run wouldn't work with a list of objects intended to be created in order, where later objects reference earlier objects (and those references are validated at create time)
We could potentially carry "dry run" down into the admission controller request path. However, a query parameter may not be appropriate, instead there's probably a HTTP header that already covers this. We try not to mix query parameters and post bodies in many cases. , Jordan Liggitt wrote:
- Thanks for advices! I'm trying to make myself thoroughly familar with request handling process. And during this period, I may need more of your help. I think I've replied this message before but unfortunately it's not showed up here:-( - Can you provide a link to the code about the HTTP header? Thanks!
This feels like a variant of an header with a sub parameter - possibly or possibly content-type . , Victor HU wrote:
+1 for this. My use case is to understand the difference between a stack file and an existing cluster, but this command would be a substitute.
It looks like support for has been . I think this issue can be closed.
We still need to make touch the server, or at least decide that we don't want to.
you mean move server side?
has just released kubeval: From to sig-apps mailing list: I am not sure if it validates the values and other constraints checked on the server-side. Just leaving it here as it might be relevant to the feature discussion. (h/t briangrant for pointing this out).
Issues go stale after 90d of inactivity.

Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
a HTTP header that already covers this. We try not to mix query parameters and post bodies in many cases. Do you remember why you said that? I'm trying to understand ...
should fix this issue, we can close it when the server-side dry-run feature reaches beta. The feature above () will fix this use-case, and even validate against the admission chain. is being built on top of server-side dry-run, and will be a good way to visualize the output of dry-run apply:
This is now beta.