Proposal: Validation enhancement

[jasmingacic]

Currently when request validation is enabled we only return error 400.

To enable users to test out their existing API clients we need to allow them to collect such information.

Proposal:

        validation:
          request:
            enabled: true
            log: true // not the best naming option 

Here we'd allow them to have combination of these.

When validation.request.enabled = true - the gateway will return only 400 Wehn validation.request.log = true - we log that information into kusk-manager logs

By combining these two parameters we can have following scenarios: Test environment

validation.request.enabled = false
validation.request.log = true

• In CI/CD users run their API clients against deployed API and collect information if some requests don't check out
• Allow legacy API clients to work and inform about what's wrong with it.

Staging

validation.request.enabled = true
validation.request.log = true

Return 400 and collect information about it.

Production

validation.request.enabled = true
validation.request.log = false

We return 400 for all requests that don't check out and log nothing. Allowing users to optimize their infra setup by allowing them to disable logging.

[aabedraba]

Perhaps it's cleaner to keep the logging functionality away from the schema, as I think that's too much implementation detail for a gateway.

As we discussed this morning, maybe we could either:

• Always run validation on POST/PUT and just log the error
• Have a different service that receives a shadow request and handles logging

I personally am much more in favor of request shadowing to a specific "Log Service" that we can use for other types of logging in the future and I feel like it will affect less the request latency.

[jasmingacic]

To enable users to analyze what requests check out and which don't we only need to add logging to our validation service.

One of options that we need to tell users how to send logs to a service of their liking.

Having shadowing is going beyond scope of this feature. Plus it doesn't solve much for the users as they need to configure another envoy cluster which would handle "shadowed" requests.

Shadowing, canary, blue/green deployment are closely related and should probably become a separate feature.

[jasmingacic]

The PR #940 has handled one piece of this which is enabling logging when validation is turned on. This way users can have visibility in what is failing. Also this would allow for prometheus or any similar tool to hook into kusk logs.