Lattice Service Name values are being shortened more than they should

[drcrees]

The current method for deriving the service name from a route is too aggressive and truncates more than it should.

I'd also like to have better control over the service name. The namespace being part of the name isn't particularly valuable to me and just consumes precious real-estate.

https://github.com/aws/aws-application-networking-k8s/blob/main/pkg/utils/common.go#L63-L65

From AWS documentation,

The name must be between 3-63 characters and use lowercase letters, numbers, and hyphens. It must begin and end with a letter or number. Do not use double hyphens.

I should be able to have a service name that is 63 characters long, not limited to 38.

[SinghVikram97]

Hi @drcrees

Thanks for pointing this out. The actual limit for service name is 3-40 characters. We have updated the documentation, sorry for the confusion.

Regarding having better control over service name, could you please share what you have in mind and how it would support your use case.

[drcrees]

That's unfortunate... perhaps support for an additional annotation on route resources to override the default service name derivation from route name and namespace name? Something like:

application-networking.k8s.aws/custom-service-name: my-awesome-api-v1

This would allow us to exclude having the namespace in the name if we want and free up 19 characters. We also wouldn't be forced to have the route name be the service name.

The main issue is, say I have two routes that use the same network in a namespace called awesome-service-api,

awesome-service-api-v1 -> awesome-service-api- (20 chars)
awesome-service-api-v2 -> awesome-service-api- (20 chars)

The controller would attempt to generate two services with the same name:
awesome-service-api--awesome-service-ap

Whereas, if we could override with an annotation or something, we'd have:
awesome-service-api-v1
awesome-service-api-v2

awesome-service-api-xxxxxxxxxxxxxxxxxxxx (so much room!)

I think we'd have a lot less accidental naming conflicts with this.

[andrei-zhytkevich-aptos-com]

We have somewhat similar use case, but we also need to take into account cluster: Lattice services for the same microservice from different clusters.
It would be nice to have a hash or something random in the name. Similar to the naming of listener rules and target groups.