Onboarding and routing to a service with invalid serviceId

[pavel-jares-bcm]

Describe the bug

The invalid serviceId (against the conformance) has an unexpected behavior.

Steps to Reproduce

1. register a service with serviceId service_test
2. try to call an endpoint ie. /service_test/api/v1
3. the response is 500

Expected behavior
It should route well or inform about wrong inputs

The root cause is that GW uses a load balancer. To identify the instance it uses a URI like lb://service_test. During the processing by the load balancer, it is necessary to parse the URI and it is a problem because the URI is not valid (for _ character - https://www.ietf.org/rfc/rfc0952.txt). It leads to internal server error 500.

Possible solution:

1. reject onboarding with invalid serviceId (or potentially other values)

• the DS could return 400 in this case
• if the service logs the reason for error it could be displayed

2. rename serviceId internally

• use as service ID encoded string (ie by using -)
• we need to provide the original serviceId in metadata to be possible to construct url for a routing rule

3. update enabler to verify this value and at least log warn message or rather stop onboarding process

Details

• Version and build number: 3.0.0

[richard-salac]

Base on the experience from the implementation we should consider adding the following requirements:

• Add the validation also to onboarding enablers.
• Log warning for conformance violation and prevent onboarding of non-conformant services few releases later to avoid a breaking change and give such services to adapt.
• Clarify documentation for enablers as they do not have a configuration option for serviceId, but app and instanceId instead. The app property is in fact appName.
• Clearly document the requirement for instanceId format. The format we validate (hostname:appname:port) is the default one used by Spring when the instance id is generated (docs), but not a hard requirement from Eureka. Maybe APIML should generate the instance id instead of relying on the service to provide a correct one.

[richard-salac]

More details about current state and issues to be resolved in the future can be found in the #4392 description.

[richard-salac]

We should also consider adding integration tests onboarding all of our enables.