skupperproject
Listener and Connector in same site incompatible with exposePodsByName
Describe the bug When a Listener and Connector are added to the same site with exposePodsByName the control plane attempts to create tcpListener and tcpConnector records with the same name, violating the unique constraint in router configuration.
How To Reproduce Steps to reproduce the behavior:
Expected behavior A clear and concise description of what you expected to happen.
Environment details
- Skupper CLI: [e.g. 1.5.0, 1.4.3]
- Skupper Operator (if applicable): [e.g. 1.5.0, 1.4.3]
- Platform: [e.g kubernetes, openshift]
Additional context Add any other context about the problem here.
Found while trying to get a quick reproducer for https://github.com/skupperproject/skupper/issues/2054
I can't think of a good use case for this to work, but it is unexpected, and I did recently try using this as a hack while working on a hazelcast demo. (as a way to make pod names resolve within a namespace.)
General naming scheme for router resources: I think we're likely to run into other sources of collisions if we look close enough.
tcpConnector
When connector host is set
Scheme [email protected] Example [email protected]
When using a selector
Scheme [email protected] Example [email protected]
When using a selector and ExposePodsByName
Scheme [email protected] Example backend@backend-76cbb78c6-79r42
tcpListener
Scheme Listener.Name Example backend
When adding a listener for ExposePodsByName
Scheme [email protected] Example backend@backend-76cbb78c6-79r42
The resource names for tcpListener and tcpConnector with ExposePodsByName clash. I believe the safest way to proceed is by adding some prefix or suffix to namespace by resource type. If we applied this broadly to all tcpListener (and tcpConnector?) resources I think we could mitigate other likely collisions (a listener resource with a name matching one of the prefixed router resources mc, amqp or amqps, a listener with the same name as a link or routeraccess resource.)
What about adding the resource kind as a prefix? The kind as a prefix prevents router resource names from clashing.
As a suffix we'd need something to make the particular kind unique, like the target hostname and port for connectors.
