cloudfoundry / cloudfoundry/capi-release
Evaluate removal of v2 api for selected vms creating different cc_ng deployment groups
Open
Nobody has claimed this yet.
performance
PoC
unscheduled
- Dominant language
- HTML
- Stars
- 24
- Forks
- 110
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 8
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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the dependency on issue #2254 and the current capi-release deployment and Gorouter registration paths for v2 and v3. Determine whether separating VMs improves stability or performance; if it does, done means a deployable capi-release branch with a flag registering only /v2 or /v3.
Written by the indexing model from the issue text.
Assessment
- Domain
- cloud, devops, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100