krane
krane copied to clipboard
Batch dry-running may fail slower than we expect
Server-side dry run can fail when an admission controller does not declare itself as having no side effects. In the case of some of our deploys, we go through the effort of dry-running every resource, only to fail on ones that go through such an admission hook. The result is a long, failed, attempt at batch running, followed by a resource-by-resource validation (which succeeds by virtue of being mostly client-side).
Three approaches that come to mind are:
- Grant the ability to pass in a denylist of resource kinds we don't want to validate server-side
- Allow explicitly declaring whether to use batch server-side dry running or client side
- Get all admission controllers and check which ones support dry-run; client-side check those resources and remove them from the batch of server-side dry-run resources