Service name generation fails due to RFC 1123 subdomain validation schema

[samox73]

The doc (https://docs.otterize.com/reference/service-identities#kubernetes-service-identity-resolution) states that the service name for pods w/o the service-name annotation is generated according to their root owner name. All the . in this name are replaced by _. However when applying the generated ClientIntents, this fails with

The ClientIntents "some-service_v0_0_1" is invalid: metadata.name: Invalid value: "some-service_v0_0_1": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

when this root owner's name is e.g. some-service.v0.0.1, which can be the case for some CRDs. In my case it was the ClusterServiceVersion of the OLM, where it is common to name the CSV according to the version, see https://olm.operatorframework.io/docs/concepts/crds/clusterserviceversion/

My proposal would be to replace all . in the root owner name with - instead to conform to this specification, making the automated generation and application of ClientIntents more resilient, without manual intervention.

[orishoshan]

Hey @samox73, thanks for the issue!

Indeed, you are correct - when generating the metadata.name we should use a different pattern, as you suggest. We'll be making this change soon :)