|
| 1 | +# Meta |
| 2 | +[meta]: #meta |
| 3 | +- Name: CF API v2 End of Life |
| 4 | +- Start Date: 2024-08-08 |
| 5 | +- Author(s): stephanme |
| 6 | +- Status: Draft <!-- Acceptable values: Draft, Approved, On Hold, Superseded --> |
| 7 | +- RFC Pull Request: [#941](https://github.com/cloudfoundry/community/pull/941) |
| 8 | + |
| 9 | + |
| 10 | +## Summary |
| 11 | + |
| 12 | +CF API v2 is deprecated since at least 2021 but there is no End of Life date communicated (see [ccng #2725](https://github.com/cloudfoundry/cloud_controller_ng/discussions/2725)). |
| 13 | + |
| 14 | +This RFC shall define a plan to disable and finally remove CF API v2 from CAPI and cf-deployment. |
| 15 | + |
| 16 | +## Problem |
| 17 | + |
| 18 | +There are several issues and efforts with keeping the deprecated CF API v2 as part of CAPI and cf-deployment: |
| 19 | + |
| 20 | +- Maintenance effort in CAPI and CF API client libraries |
| 21 | +- CF API v2 uses a different Ruby web framework than v3 |
| 22 | +- Shipping an API that is not well tested anymore: CATS don’t test CF API v2 |
| 23 | +- Performance problems especially in large foundations: metrics show that v2 requests take between 3 to 5 times as long as v3 requests on average |
| 24 | +- Larger cloud controller database schema refactorings/improvements are not possible or at least difficult because the same DB schema has to serve v2 and v3. This blocks performance improvements in CF API v3. |
| 25 | + - Example: [ccng decision 0007-implementing-v3-roles.md](https://github.com/cloudfoundry/cloud_controller_ng/blob/main/decisions/0007-implementing-v3-roles.md) |
| 26 | + - Areas where schema changes could lead to performance improvements: roles, service plan visibilities |
| 27 | +- More fine grained org and space roles, a recurring user request, would benefit from a DB schema migration away from the current one table per role design. Blocked as well by CF API v2. |
| 28 | + |
| 29 | +## Proposal |
| 30 | + |
| 31 | +Since CF API v2 removal is a fundamental breaking change, the removal is divided into 3 phases of about 1 year each with checkpoints in between that require TOC approval. |
| 32 | +If the TOC does not approve moving to the next phase, the TOC will decide a number of months to extend the current phase. Subsequent phases and the EoL date will be updated accordingly. The TOC will then re-convene after that period to again evaluate if it is appropriate to move to the next phase. |
| 33 | + |
| 34 | +**Phase 1** (starts after accepting this RFC) |
| 35 | +- Announce an End of Life date for CF API v2 (~ mid/end 2026). |
| 36 | +- Engineering work so that all cf-deployment components are built/tested/released with v2 turned off |
| 37 | +- Turn off CF API v2 by default in cf-deployment (set CAPI property [cc.temporary_enable_v2](https://bosh.io/jobs/cloud_controller_ng?source=github.com/cloudfoundry/capi-release&version=1.185.0#p%3dcc.temporary_enable_v2) to false). Operators may still re-enable v2. |
| 38 | + |
| 39 | +**Checkpoint 1** |
| 40 | +- TOC approval |
| 41 | + |
| 42 | +**Phase 2** (after Checkpoint 1, ~mid/end 2025) |
| 43 | +- Engineering work so that all CFF-controlled clients use v3 by default |
| 44 | +- Window for 3rd-party clients to complete migration to v3 |
| 45 | + |
| 46 | +**Checkpoint 2** |
| 47 | +- TOC approval |
| 48 | + |
| 49 | +**Phase 3** (after Checkpoint 2, ~mid/end 2026) |
| 50 | +- Turn CF API v2 permanently off for CAPI/cf-deployment. |
| 51 | +- Engineering work to remove CF API v2 from CAPI. |
| 52 | + |
| 53 | +### Impact and Consequences |
| 54 | + |
| 55 | +- CF API client libraries like [cf-java-client](https://github.com/cloudfoundry/cf-java-client), [cf-goclient](https://github.com/cloudfoundry/go-cfclient) and [cf_exporter](https://github.com/cloudfoundry/cf_exporter) should plan for closing gaps in CF API v3 support and for removing their CF API v2 implementation. |
| 56 | +- CF CLI v6 and v7 still use CF API v2 and will stop working against foundations with disabled CF API v2. CF CLI v8 doesn’t use CF API v2 anymore (exception: CLI plugins, see next point). |
| 57 | +- Most CF CLI plugins rely on CF API v2. A new CF CLI plugin interface should be defined (out of scope of this RFC). However, it is possible to implement a CLI plugin without using CF API v2. |
| 58 | +- Cloud Foundry users and operators may use tooling and CI/CD pipelines which still rely on CF API v2 and therefore have migration efforts. |
| 59 | + |
| 60 | +CF API v2 specific rate limiting and the feature flag to disable CF API v2 completely is already implemented in CAPI. |
| 61 | +The [CF API v3 Upgrade Guide](https://v3-apidocs.cloudfoundry.org/index.html#upgrade-guide) helps authors of CF api clients to migrate from v2 to v3. |
0 commit comments