if use long project name autogenerated resource names might be longer than 63 characters

[maratsal]

Bug Report

What did you do?

generate project with command:

operator-sdk init --plugins helm --domain $(DOMAIN) --group $(GROUP) --version $(APIVERSION) --kind $(KIND) --helm-chart=../charts/$@/ --project-name my-random-long-project-name-1

This will initiate project and as an example one of the service name would be longer than 63 characters allowed by k8s and this will cause problem with deployment of operator. Please see below for the error message from OLM (got it from subscription details):

error updating service: my-random-long-project-name-1-controller-manager-metrics-service: Service "my-random-long-project-name-1-controller-manager-metrics-service" is invalid: metadata.name: Invalid value: "my-random-long-project-name-1-controller-manager-metrics-service": must be no more than 63 characters

What did you expect to see?

I would expect warning or failure of operator-sdk init, or some kind of truncation of the name to be within the limits.

What did you see instead? Under which circumstances?

operator sdk created operator and I could identify the problem only on the testing phase.

Environment

Operator type:

Operator type: /language helm

Kubernetes cluster type:

OpenShift

$ operator-sdk version

operator-sdk version: "v1.22.2", commit: "da3346113a8a75e11225f586482934000504a60f", kubernetes version: "1.24.1", go version: "go1.18.4", GOOS: "darwin", GOARCH: "amd64"

$ kubectl version

Client Version: version.Info{Major:"1", Minor:"20+", GitVersion:"v1.20.8-dispatcher", GitCommit:"283881f025da4f5b3cefb6cd4c35f2ee4c2a79b8", GitTreeState:"clean", BuildDate:"2021-09-14T05:14:54Z", GoVersion:"go1.15.13", Compiler:"gc", Platform:"darwin/amd64"}

Possible Solution

I would expect warning or failure of operator-sdk init, or some kind of truncation of the name to be within the limits.

Additional context

N/A

[camilamacedo86]

That is not a bug it is a validation. The name is used to create the namespace. Therefore, k8s has a limit of size which needs to be respected.

[maratsal]

That is not a bug it is a validation. The name is used to create the namespace. Therefore, k8s has a limit of size which needs to be respected.

in this particular case the problem no with the namespace name, but service name for the metrics service my-random-long-project-name-1-controller-manager-metrics-service.

I felt that operator sdk should not be generating manifests that are not deployable on k8s, i.e. either provide warning or fail init command, or have some prerequisites on project name length.

[camilamacedo86]

Hi @maratsal,

I understand the problem. We check the name of the project here: https://github.com/kubernetes-sigs/kubebuilder/blob/master/pkg/plugins/common/kustomize/v1/init.go#L95-L97 (SDK uses Kubebuilder as lib)

So, we need to figure out:

• a) Do we need to reduce the size allowed for the project name? If so the solution is in the Kubebuilder OR
• b) No matter the size it will never fail. Could you test it out with a bigger name and let us know if it will be allowed or not?

[maratsal]

hi @camilamacedo86,

Let me post commands here to reproduce the issue. You can run following and you will get service name that is longer than 63 characters:

$ operator-sdk init --plugins helm --domain mydomain.com --group mygroup --version v1alpha1 --kind Nginx --helm-chart=bitnami/nginx --project-name my-random-long-project-name-nginx
Writing kustomize manifests for you to edit...
Creating the API:
$ operator-sdk create api --group mygroup --version v1alpha1 --kind Nginx --helm-chart bitnami/nginx
Writing kustomize manifests for you to edit...
Created helm-charts/nginx
W0816 08:10:42.188974   70636 gcp.go:120] WARNING: the gcp auth plugin is deprecated in v1.22+, unavailable in v1.25+; use gcloud instead.
To learn more, consult https://cloud.google.com/blog/products/containers-kubernetes/kubectl-auth-changes-in-gke
Generating RBAC rules
WARN[0009] The RBAC rules generated in config/rbac/role.yaml are based on the chart's default manifest. Some rules may be missing for resources that are only enabled with custom values, and some existing rules may be overly broad. Double check the rules generated in config/rbac/role.yaml to ensure they meet the operator's permission requirements. 
$ 
$ 
$ 
$ make bundle
operator-sdk generate kustomize manifests -q

Display name for the operator (required): 
> nginx operator

Description for the operator (required): 
> nginx operator

Provider's name for the operator (required): 
> nginx operator

Any relevant URL for the provider name (optional): 
> 

Comma-separated list of keywords for your operator (required): 
> nginx

Comma-separated list of maintainers and their emails (e.g. 'name1:email1, name2:email2') (required): 
> [email protected]
cd config/manager && /usr/local/bin/kustomize edit set image controller=controller:latest
/usr/local/bin/kustomize build config/manifests | operator-sdk generate bundle -q --overwrite --version 0.0.1  
INFO[0000] Creating bundle.Dockerfile                   
INFO[0000] Creating bundle/metadata/annotations.yaml    
INFO[0000] Bundle metadata generated suceessfully       
operator-sdk bundle validate ./bundle
INFO[0000] All validation tests have completed successfully 
$ ag controller-manager-metrics-service
config/rbac/auth_proxy_service.yaml
6:  name: controller-manager-metrics-service

bundle/manifests/my-random-long-project-name-nginx-controller-manager-metrics-service_v1_service.yaml
7:  name: my-random-long-project-name-nginx-controller-manager-metrics-service
$ echo my-random-long-project-name-nginx-controller-manager-metrics-service | wc -c
      69
$

So basically this manifest's service name gets longer than 63 characters: bundle/manifests/my-random-long-project-name-nginx-controller-manager-metrics-service_v1_service.yaml

I think operator-sdk should be catching the problem either when we are running operator-sdk generate kustomize manifests -q or on the operator-sdk bundle validate ./bundle but in fact it is not happening.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten /remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen. Mark the issue as fresh by commenting /remove-lifecycle rotten. Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci[bot]]

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen. Mark the issue as fresh by commenting /remove-lifecycle rotten. Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.