App name cannot have more than 63 characters

[DimpleRajaVamsi]

What steps did you take:
Created an app with the app name having more than 63 characters.

What happened:
App creation failed because the app-change ConfigMaps uses the app name as a label.

kapp: Error: Creating app change:
  ConfigMap "byoi-2213-photon-ns-antrea-11ns1-c1-guest-cluster-auth-serzfmpw" is invalid: metadata.labels:
    Invalid value: "byoi-2213-photon-ns-antrea-11ns1-c1-guest-cluster-auth-service-ctrl": must be no more than 63 characters

What did you expect:
App to be created successfully.

Anything else you would like to add:
This causes issues for App CRs and PackageInstall CRs from kapp-controller because a kapp app is created using the name of app/package install.

Environment:

• kapp version (use kapp --version): kapp controller version is v0.41.2
• OS (e.g. from /etc/os-release): Photon
• Kubernetes version (use kubectl version): 1.22.13

---

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.

[praveenrewar]

Currently, the app name is used to generate the label value for the app-change-app label in the app change ConfigMaps, so if the app name is more than 63 characters, the label value becomes invalid as there is a limit on the number of characters for a label.

We will use a different property (the label generated by kapp for each app) of an app to generate the label key in app change ConfigMaps. The label generated by kapp is unique for an app and it has limited number of characters so the app name length won't effect it.

Current

App Name -> just-another-name
kapp.k14s.io/app-change-app -> just-another-name

Proposed

App Name -> just-another-name
kapp generated label -> 19023903840
kapp.k14s.io/app-change-app -> 19023903840

However doing so would introduce a breaking change in terms of how app-changes are generated, listed and deleted.
We can also make this behaviour opt-in so that folks can migrate to it when they feel comfortable in doing so, but that would add an extra overhead in terms of release of the change (i.e. releasing it as opt in first and in future versions making it opt out and then mandatory).

Adding a few scenarios to elaborate both the approaches:

1. Introduce it as a breaking change

kapp version	new app-changes	old app-changes	Remark
Newer versions	✅	❌	kubectl can be used to view/update old app-changes if required. Or we can accommodate old app-changes at the cost of few additional API calls to the server.
Older versions	❌	✅	There's nothing we can do about the new app-changes

2. Introduce it as an opt-in breaking change

Environment variable is set to true

kapp version	new app-changes	old app-changes	Remark
Newer versions	✅	❌	kubectl can be used to view/update old app-changes if required. Or we can accommodate old app-changes at the cost of few additional API calls to the server.
Older versions	❌	✅	There's nothing we can do about the new app-changes

Environment variable is set to false

kapp version	new app-changes	old app-changes	Remark
Newer versions	❌	✅	Same as older versions
Older versions	❌	✅

In future versions, the environment variable will be set to to true by default and the feature would then become opt-out (deprecated) and then after some more releases, old feature will be removed completely.