App name cannot have more than 63 characters
DimpleRajaVamsi opened this issue Β· comments
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 isv0.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.
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.