mirror of
https://github.com/elastic/kibana.git
synced 2025-04-23 09:19:04 -04:00
bc434697c9
# Backport This will backport the following commits from `main` to `8.x`: - [[Http] Gracefully onboarding internal routes to `VersionedRouter` (#194789)](https://github.com/elastic/kibana/pull/194789) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Jean-Louis Leysens","email":"jeanlouis.leysens@elastic.co"},"sourceCommit":{"committedDate":"2024-10-04T06:47:36Z","message":"[Http] Gracefully onboarding internal routes to `VersionedRouter` (#194789)\n\n## Summary\r\n\r\nIf an internal route goes from unversioned -> versioned today this will\r\nsurface as a breaking change. This PR allows internal routes to\r\ngracefully onboard to the versioned router.\r\n\r\nThe fix is to default to version `1` of an internal route if no version\r\nis provided. In this way old clients can continue to interact with the\r\nnew servers as developers onboard to the versioned router and roll out\r\nv2+ of an internal route.\r\n\r\n## Notes\r\n\r\nWe could use `buildNr` to narrow down internal routes defaulting to v1\r\nto older clients only. IMO this would be more accurate, but also of\r\nmarginal value. My rationale is: by requiring explicit versions during\r\ndev time the risk of us shipping new builds that don't provide a version\r\nis effectively nullified. Additionally we already run this risk with our\r\npublic route default behaviour (we even require that public routes have\r\nexplicit version in dev to mitigate this same risk for existing public\r\nclients).\r\n\r\nIf reviewers feel otherwise I'm happy to revisit this!\r\n\r\n### Checklist\r\n\r\nDelete any items that are not applicable to this PR.\r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n\r\n### Risk Matrix\r\n\r\n| Risk | Probability | Severity | Mitigation/Notes |\r\n\r\n|---------------------------|-------------|----------|-------------------------|\r\n| By defaulting internal routes to v1 it's possible that behaviour\r\nbecomes less predictable. | Low | Low | This is already true for public\r\nroutes and we are allowing a more limited/more predictable version of\r\nthat here. |","sha":"afecfd8889b042501d8de72b6eb6d8a1b98cb586","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:http","Team:Core","release_note:skip","v9.0.0","v8.16.0","backport:version"],"title":"[Http] Gracefully onboarding internal routes to `VersionedRouter`","number":194789,"url":"https://github.com/elastic/kibana/pull/194789","mergeCommit":{"message":"[Http] Gracefully onboarding internal routes to `VersionedRouter` (#194789)\n\n## Summary\r\n\r\nIf an internal route goes from unversioned -> versioned today this will\r\nsurface as a breaking change. This PR allows internal routes to\r\ngracefully onboard to the versioned router.\r\n\r\nThe fix is to default to version `1` of an internal route if no version\r\nis provided. In this way old clients can continue to interact with the\r\nnew servers as developers onboard to the versioned router and roll out\r\nv2+ of an internal route.\r\n\r\n## Notes\r\n\r\nWe could use `buildNr` to narrow down internal routes defaulting to v1\r\nto older clients only. IMO this would be more accurate, but also of\r\nmarginal value. My rationale is: by requiring explicit versions during\r\ndev time the risk of us shipping new builds that don't provide a version\r\nis effectively nullified. Additionally we already run this risk with our\r\npublic route default behaviour (we even require that public routes have\r\nexplicit version in dev to mitigate this same risk for existing public\r\nclients).\r\n\r\nIf reviewers feel otherwise I'm happy to revisit this!\r\n\r\n### Checklist\r\n\r\nDelete any items that are not applicable to this PR.\r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n\r\n### Risk Matrix\r\n\r\n| Risk | Probability | Severity | Mitigation/Notes |\r\n\r\n|---------------------------|-------------|----------|-------------------------|\r\n| By defaulting internal routes to v1 it's possible that behaviour\r\nbecomes less predictable. | Low | Low | This is already true for public\r\nroutes and we are allowing a more limited/more predictable version of\r\nthat here. |","sha":"afecfd8889b042501d8de72b6eb6d8a1b98cb586"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/194789","number":194789,"mergeCommit":{"message":"[Http] Gracefully onboarding internal routes to `VersionedRouter` (#194789)\n\n## Summary\r\n\r\nIf an internal route goes from unversioned -> versioned today this will\r\nsurface as a breaking change. This PR allows internal routes to\r\ngracefully onboard to the versioned router.\r\n\r\nThe fix is to default to version `1` of an internal route if no version\r\nis provided. In this way old clients can continue to interact with the\r\nnew servers as developers onboard to the versioned router and roll out\r\nv2+ of an internal route.\r\n\r\n## Notes\r\n\r\nWe could use `buildNr` to narrow down internal routes defaulting to v1\r\nto older clients only. IMO this would be more accurate, but also of\r\nmarginal value. My rationale is: by requiring explicit versions during\r\ndev time the risk of us shipping new builds that don't provide a version\r\nis effectively nullified. Additionally we already run this risk with our\r\npublic route default behaviour (we even require that public routes have\r\nexplicit version in dev to mitigate this same risk for existing public\r\nclients).\r\n\r\nIf reviewers feel otherwise I'm happy to revisit this!\r\n\r\n### Checklist\r\n\r\nDelete any items that are not applicable to this PR.\r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n\r\n### Risk Matrix\r\n\r\n| Risk | Probability | Severity | Mitigation/Notes |\r\n\r\n|---------------------------|-------------|----------|-------------------------|\r\n| By defaulting internal routes to v1 it's possible that behaviour\r\nbecomes less predictable. | Low | Low | This is already true for public\r\nroutes and we are allowing a more limited/more predictable version of\r\nthat here. |","sha":"afecfd8889b042501d8de72b6eb6d8a1b98cb586"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Jean-Louis Leysens <jeanlouis.leysens@elastic.co> |
||
|---|---|---|
| .. | ||
| basic | ||
| common | ||