Add DryRun option to the client #831
Assignees
Labels
kind/feature
Categorizes issue or PR as related to a new feature.
lifecycle/active
Indicates that an issue or PR is actively being worked on by a contributor.
Milestone
Comments
k8s-ci-robot
added
the
kind/feature
|
/assign |
|
/lifecycle active |
k8s-ci-robot
added
the
lifecycle/active
bjhaid
added a commit
to bjhaid/kustomize-controller
that referenced
this issue
Jan 4, 2022
The code is this changeset is a minimal PoC that proofs that the ideas are possible and should be treated as such, should not be used in the real world. This leverages the work here: kubernetes-sigs/controller-runtime#831 to add dry-run support to kustomize-controller. The use case for this is purely in CI/dev. dev story - developer makes changes to YAML manifests managed by flux. - developer runs `dry-run` against a specific kustomization resource and sees what the effect of their changes are locally. CI story - A change request is made that contains updates to YAML manifests managed by flux. - CI merges the change into the main branch. - CI runs `dry-run` against a preconfigure kustomization resource and posts the effect of the changes as a comment on the pull request. It is important to note that the act of merging changes and posting a comment are completely outside the scope of this change and the kustomize-controller, this is just an example. The ideal final state for this will be in the flux cli, with helm and non-git sources support built in, as well as support for deletion dry-run. Some additonal changes that should happen to the controller: - make `finalize` a public method so it can be used to simulate deletions, so `flux delete --dry-run foo` becomes possible. - make `ExternalEventRecorder` an interface, that way the events are logged as the dry run output rather than relying on the controller's log output. ## FAQ - Why not implement this completely outside the controller? The `Reconcile` method has changed a bunch of times and may be subject to change, hence it is important that the dry-run logic completely simulates the controller behavior.
bjhaid
added a commit
to bjhaid/kustomize-controller
that referenced
this issue
Jan 4, 2022
The code in this changeset is a minimal PoC that proves that the ideas are possible, it should be treated as such and should not be used in the real world. This leverages the work here: kubernetes-sigs/controller-runtime#831 to add dry-run support to kustomize-controller. The use case for this is purely in CI/dev. dev story - developer makes changes to YAML manifests managed by flux. - developer runs `dry-run` against a specific kustomization resource and sees what the effect of their changes are locally. CI story - A change request is made that contains updates to YAML manifests managed by flux. - CI merges the change into the main branch. - CI runs `dry-run` against a preconfigure kustomization resource and posts the effect of the changes as a comment on the pull request. It is important to note that the act of merging changes and posting a comment are completely outside the scope of this change and the kustomize-controller, this is just an example. The ideal final state for this will be in the flux cli, with helm and non-git sources support built in, as well as support for deletion dry-run. Some additonal changes that should happen to the controller: - make `finalize` a public method so it can be used to simulate deletions, so `flux delete --dry-run foo` becomes possible. - make `ExternalEventRecorder` an interface, that way the events are logged as the dry run output rather than relying on the controller's log output. ## FAQ - Why not implement this completely outside the controller? The `Reconcile` method has changed a bunch of times and may be subject to change, hence it is important that the dry-run logic completely simulates the controller behavior.
bjhaid
added a commit
to bjhaid/kustomize-controller
that referenced
this issue
Jan 4, 2022
The code in this changeset is a minimal PoC that proves that the ideas are possible, it should be treated as such and should not be used in the real world. This leverages the work here: kubernetes-sigs/controller-runtime#831 to add dry-run support to kustomize-controller. The use case for this is purely in CI/dev. dev story - developer makes changes to YAML manifests managed by flux. - developer runs `dry-run` against a specific kustomization resource and sees what the effect of their changes are locally. CI story - A change request is made that contains updates to YAML manifests managed by flux. - CI merges the change into the main branch. - CI runs `dry-run` against a preconfigure kustomization resource and posts the effect of the changes as a comment on the pull request. It is important to note that the act of merging changes and posting a comment are completely outside the scope of this change and the kustomize-controller, this is just an example. The ideal final state for this will be in the flux cli, with helm and non-git sources support built in, as well as support for deletion dry-run. Some additonal changes that should happen to the controller: - make `finalize` a public method so it can be used to simulate deletions, so `flux delete --dry-run foo` becomes possible. - make `ExternalEventRecorder` an interface, that way the events are logged as the dry run output rather than relying on the controller's log output. ## FAQ - Why not implement this completely outside the controller? The `Reconcile` method has changed a bunch of times and may be subject to change, hence it is important that the dry-run logic completely simulates the controller behavior. - Why not use `kustomize build . | kubectl apply --dry-run=server -f -`: This will not account for deltas removed from the changeset as compared to the base, so deletions will not reflect.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In order to safely check on what a controller does in a production environment, it would be useful to have a
DryRunoption for the client that makes all mutating operations (Update,PatchandDelete) a no-op and just logs them./kind feature
The text was updated successfully, but these errors were encountered: