Enhance `kapp rename` to handle app-changes

[100mik]

Describe the problem/challenge you have As of today, on renaming an app using kapp rename the app-change config maps are not renamed and lost. They are not moved when the --new-namespace flag is used either.

Describe the solution you'd like

• Improve how rename works so that it handles app-changes
• This behaviour could be toggled with a flag.

Adding the following flags might give the user more control over what happens to app-changes while renaming :

• --rename-app-changes
  • boolean flag
  • default false (which is the behaviour observed today)
  • Let's the user decide whether or not he wants to move and rename the app-changes while moving the kapp ConfigMaps to a new namespace.
• --max-app-changes
  • Let's the user specify the number of newest changes that they want to rename and move

Anything else you would like to add: Worth considering whether or not we wanna delete and take care of residual config maps if the user moves/renames a certain number of config maps. Might be worth it if it does not add too much complexity.

---

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.

[100mik]

This post is motivated by the enhancement in #338 which might lead to the user wanting to handle app changes better since they have more value.