kubectl --dry-run

[bgrant0607]

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.

[smarterclayton]

For generator types commands, I think there is a usability argument that the default when a user specifies -o * should be to dry-run (and a user should be allowed to override that with --dry-run=false). 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 create -f -).

I'm somewhat partial to having kubectl expose and kubectl run support the presence of -o changing the default of dry-run to true, because that's more common and easier than having to set --dry-run=true and -o yaml. The counter argument is that --dry-run is the preferred action, and -o 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 -o yaml --dry-run=true to review the change, and then if they want to create it they can pipe to kubectl reconcile -f - or kubectl create -f - 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.

[jonmoter]

👍 for this feature. In particular, I would like an ability to validate an object definition separate from actually creating the object.

e.g. running kubectl create --validate=true --dry-run -f pod.yml at the validation step of my deployment pipeline.

[bgrant0607]

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.

[hurf]

@bgrant0607 - I'm planning to add a parameter dryrun 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?

[liggitt]

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)