Don't update immutable fields when adopting resources deployed by other tools

[cari-lynn]

Describe the problem/challenge you have Given I have deployed resources with kubectl When I deploy updates to those resources with kapp Then I expect that kapp is able to adopt those resources, apply the changes and not error

Currently, when deploying kapp will sometimes error with field is immutable (reason: Invalid) when it is updating a label for a resource where that field is immutable.

Describe the solution you'd like I would like kapp to adopt and apply the changes to the resources without error

Anything else you would like to add: When trying to update label selectors kapp will error when adopting existing resources not deployed by kapp and the person deploying currently needs to decide what strategy that is best for them to fall back on.

There are (at least) these two strategies to solve this:

• Not update label selectors (using kapp.k14s.io/disable-default-label-scoping-rules: ""`). This has no effect on kapp's ability to track resources but must be added to the annotations on each resource that it is needed for.
• Delete and update the resource (via kapp.k14s.io/update-strategy: fallback-on-replace annotation) so that the label selectors can be applied. This has downtime implications.

The purpose of this issue is to track considerations in how to solve this

The decision to require updating these immutable fields was made to add labels that may be helpful in grouping resources. However, with what we know now and that this isn't a required feature of kapp, we may want to reevaluate this and look for a way to make it 'opt-in' instead. Although, this may have implications for backwards compatibility so we may want to consider adding a flag to to change this behavior.

Related issues: #204 #138

---

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible" 👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

[pivotaljohn]

Removed carvel-triage label: there's enough interest, there's identified value, and we have enough precision in the request to consider it Added discussion label: we're hashing out what's the right approach to meet this need, generally.