Evaluate removal of v2 api for selected vms creating different cc_ng deployment groups #218
Description
Dependencies
depends on
- #2254 Just makes sense in case we dont use puma
Issue
The v2 code has quite bad performance and we dont anticipate to improve anything in v2 since there is v3 already productive.
Yet current architecture of CC where one has 20 threads shares them between v2 and v3 calls. If a lot of slow v2 calls fill up this queue of 20 slots, we have an issue also for v3
Acceptance Criteria
- See if this really benefits stabillity/performance if we have vms that handle v2 and different ones that handle v3
- If so, we want to have a branch with a deployable capi-release that has a flag to register just the /v2 or /v3 path towards gorouter and thus create this seperation