# Handling status in diff stage --- ###### tags: `kapp` --- ## Summary Use `diffAgainstLastAppliedFieldExclusionRules` to exclude `status` field in diffing against last applied. ## Motivation Currently rebase rules are used to copy the `status` field from the existing resource to the applied resource to make sure that unwanted diffs are not produced. However, this causes issues if the resource version needs to be updated and the newer version has a different format for status. The rebase rule also doesn't allow users to modify the status (if required). ## Proposal Use `diffAgainstLastAppliedFieldExclusionRules` to exclude `status` field in diffing against last applied. This will ignore the `status` field while generating the original-diff-md5 [[1]](#[1]) and thereby not generating unwanted diffs on subsequent deploys due to changes made by the controllers on the status field. This also allows users to make changes to the status field if required and also be able to see the diff for the changes in status. ## Example deploy ```bash $ kapp deploy -a simple-app -f https://raw.githubusercontent.com/vmware-tanzu/carvel-kapp/develop/examples/simple-app-example/config-1.yml ...snip... Namespace Name Kind Age Op Op st. Wait to Rs Ri default simple-app Deployment - create - reconcile - - ^ simple-app Service - create - reconcile - - ...snip... # subsequent deploy with no change ...snip... Namespace Name Kind Age Op Op st. Wait to Rs Ri Op: 0 create, 0 delete, 0 update, 0 noop, 0 exists Wait to: 0 reconcile, 0 delete, 0 noop ...snip... # subsequent deploy with changing targetPort to 81 in service ...snip... @@ update service/simple-app (v1) namespace: default @@ ... 43, 43 - port: 80 44 - targetPort: 80 44 + targetPort: 81 45, 45 selector: 46, 46 kapp.k14s.io/app: "1659558599172960000" ...snip... #subsequent deploy with adding a random key value pair in status of deployment ...snip... @@ update deployment/simple-app (apps/v1) namespace: default @@ ... 121,121 name: simple-app 122 + status: 123 + key: value 122,124 ...snip... # subsequent deploy with no change ...snip... Namespace Name Kind Age Op Op st. Wait to Rs Ri Op: 0 create, 0 delete, 0 update, 0 noop, 0 exists Wait to: 0 reconcile, 0 delete, 0 noop ...snip... ``` ## Implementation When using the "smart" diff [[1]](#[1]), the last applied resource (with existing resource from cluster rebased onto it) is treated as the existing resource to generate the diff. With the removal of the current rebase rule to copy status, the last applied resource (being treated as the existing resource) won't have the information required for kapp to determine the current state of the app. To overcome this, we will save the original resource from cluster as it is into a new field which will be used only to determine the current state of the cluster. Therefore, we need to: - Add `status` as a path under `diffAgainstLastAppliedFieldExclusionRules`. - Save a copy of unmodified existing resource to determinue current state. Experimental PR: https://github.com/vmware-tanzu/carvel-kapp/pull/569 ## [1] When a resource is created on the cluster, kapp saves the original resource that was applied into the annotation kapp.k14s.io/original and the md5 hash of the difference between the original resource and the resource that exists on the cluster into the annotaion called kapp.k14s.io/original-diff-md5. This is lated used to generate a "smart" diff on subsequent deploys.