Uri shortener for long host label endpoints

[guicassolato]

It will automatically shorten host labels of system-generated proxy endpoints, that exceed the 63-char limit imposed by RFC-1035.

Closes THREESCALE-5089

[Martouta]

👏 💪 🥇 🎉 🕺 💃

[hallelujah]

I wonder, instead of using system_name and tenant_name can't we just generate a UUID?
OK UUID is not user friendly but typing by hand 63+ chars in a URL without error is unlikely

The route created in OpenShift could have annotations to query by system_name and tenant_name.
WDYT?

[guicassolato]

I wonder, instead of using system_name and tenant_name can't we just generate a UUID?

I think the problem is that this will become the public URL of the service. Customers will probably prefer keep getting something easier to remember and yet still be more or less in control of the host name (up to a point).

[hallelujah]

I really do not know, it is a copy paste anyway, used in scripts not something you type in your browser url bar.

[guicassolato]

@hallelujah, the 63-char limit per hostname label is currently being easily reached in Openshift when service discovery is used because we generate the system name. It's not (directly) chosen by the customer. It's "#{openshift_namespace}-#{service_name}". And then system name of the service is used in the template to generate the proxy endpoints, where we append yet "-#{tenant_org_name}"-apicast-staging or "-#{tenant_org_name}"-apicast-production.

About how the endpoints are used afterwards, I really don't know. You may be right. I just didn't wanna break behaviour too much.

[hallelujah]

I was thinking of using a UUID or something instead of the template when it is generated by ServiceDiscovery
Because shortening is prone to name collision.

2 services with long enough name can generate a similar system name that will be shortened, leading to 2 generated same URLs pointing to 2 services (one accepted by OpenShift, the other not)

[guicassolato]

I was thinking of using a UUID or something instead of the template when it is generated by ServiceDiscovery
Because shortening is prone to name collision.

2 services with long enough name can generate a similar system name that will be shortened, leading to 2 generated same URLs pointing to 2 services (one accepted by OpenShift, the other not_
We can then add annotations to the route so it fixes the issue once and for all

@hallelujah, that's why I used a SHA-1 based on the original hostname label. The chance of name collision here is virtually zero (or as low as SHA-1 algorithm has to generate two hashes with the same 7-char prefix for two different sources). In other words, given that "#{openshift_namespace}-#{service_name}" has to be unique, we have pretty much the same risk of generating duplicate hostnames as, e.g., git has of generating two short commit hashes 😉.

[hallelujah]

Right! I thought it was truncate then SHA1. Sorry I am tired :(

Good job @guicassolato 🎖️ 🚀