clusterserviceversion.yaml.tpl still contains reference to ServiceID in code-generator

[trgeiger]

Describe the bug
A concise description of what the bug is.

Commit 15c7f5c730d71f54af0f42499d7f9196248a375f in code-generator removed the ServiceID metadata variable which is still being used in once in clusterserviceversion.yaml.tpl. This breaks the OLM build-controller process.

Steps to reproduce

Attempt to ACK_GENERATE_OLM=true make build-controller SERVICE=$SERVICE with latest main commits.

Expected outcome
A concise description of what you expected to happen.

Build should work without issues.

Environment

• Kubernetes version
• Using EKS (yes/no), if so version?
• AWS service targeted (S3, RDS, etc.)
  Should be an issue on any service.

[vijtrip2]

Hi @trgeiger , there is already a PR open which brings ServiceID back
aws-controllers-k8s/code-generator#213 so this OLM build will fix as soon as that PR merges.

---

For future changes to catch these errors before PR gets merged, I will add OLM tests that will run on every code-generator PR submission. This will make sure OLM functionality is not broken by the PR changes.

[acornett21]

Thanks @vijtrip2 let us know if you want us to review the tests you create.

[vijtrip2]

Hi @acornett21 , does following qualify as a successful test ? If yes, then I can add success of this command as validation in PR tests.

➜  code-generator git:(main) ACK_GENERATE_OLM=true make build-controller SERVICE=$SERVICE
building ack-generate ... ok.
==== building s3-controller ====
Copying common custom resource definitions into s3
Building Kubernetes API objects for s3
Generating deepcopy code for s3
Generating custom resource definitions for s3
Building service controller for s3
Generating RBAC manifests for s3
Running gofmt against generated code for s3
Updating additional GitHub repository maintenance files
==== building s3-controller release artifacts ====
Building release artifacts for s3-v0.0.5
Generating common custom resource definitions
Generating custom resource definitions for s3
Generating RBAC manifests for s3
Generating operator lifecycle manager bundle assets for s3
Generating bundle version 0.0.5
Generating bundle manifests
WARN[0000] ClusterServiceVersion validation: [OperationFailed] provided API should have an example annotation 
Bundle manifests generated successfully in bundle
Generating bundle metadata
INFO[0000] Creating bundle.Dockerfile                   
INFO[0000] Creating bundle/metadata/annotations.yaml    
INFO[0000] Bundle metadata generated suceessfully       
INFO[0000] Found annotations file                        bundle-dir=../s3-controller/olm/bundle container-tool=docker
INFO[0000] Could not find optional dependencies file     bundle-dir=../s3-controller/olm/bundle container-tool=docker
WARN[0000] Warning: Value services.k8s.aws/v1alpha1, Kind=AdoptedResource: provided API should have an example annotation 
INFO[0000] All validation tests have completed successfully 

---

• I used the s3 controller, but is there a candidate service-controller which you would like me to add for OLM functionality verification?
• I don't think any of the controller currently have "/olm/olmconfig.yaml". Do you add that config file first and then generate the controller?

[acornett21]

@vijtrip2 we have been testing with s3 and elasticache I think testing with either is fine. From an OLM prospective as long as the last line is INFO[0000] All validation tests have completed successfully this indicates a success, the WARNS in the middle we tend to ignore since the service API's (ie the actually s3 api's) move faster then the yamls everyone is pre-staging in the various controllers.

For the second question, we have /olm/olmconfig.yaml prestaged in a few repos, so that is a static file that needs to be present inside a repo before we generate the OLM bundle.

Please let us know if anything needs further clarification! Thanks again for the help.

[trgeiger]

Whoops, mis-clicked!

[vijtrip2]

Thanks @acornett21

we have been testing with s3 and elasticache

Great, I will add the test to generate s3-controller with ACK_GENERATE_OLM = true

---

we have /olm/olmconfig.yaml prestaged in a few repos, so that is a static file that needs to be present inside a repo before we generate the OLM bundle.

Is this necessary step? If yes, Can you please add this file in s3-controller and raise a PR for it? @jaypipes , will that be alright?

If adding olmconfig.yaml files in main branch of s3-controller is not an option, I can add it in a separate GH branch and test can curl the file and add that file in repo during test.

Can you please paste the content of olm/olmconfig.yaml for s3-controller?

[acornett21]

@vijtrip2 The file is in main in the s3-controller controller already. We might be talking about different things, the file I am talking about is below.

https://github.com/aws-controllers-k8s/s3-controller/blob/main/olm/olmconfig.yaml

[vijtrip2]

Thanks, My bad! I overlooked it.

[trgeiger]

Should we close this since the original bug is fixed now? Happy to keep open for the testing bit, but maybe we should track that in a separate issue?

[vijtrip2]

Yeah, I will create a separate issue for adding the test.