For various features or security fixes, we have used proto3 fields to
control enablement. These have often been scalar fields and default
disabled due to potential data plane breakages. When the time comes for
these to be default enabled, there is no way to do this client-side
without API breaking changes.
This change to API style encourages use of WKTs for scalars in this
situation, since they can have defaults changes on a per-xDS client
basis without any API breaking change.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 1942151aafceee50630572c82cc40d220ec4a63c
* API review checklist
Signed-off-by: Mark D. Roth <roth@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ b501569e116a3d17e93dd19f16b076ee513f90ea
* xds: refactor and update API principles.
* Remove API_OVERVIEW.md, the content here is really stale and reflects
the v1 -> v2 migration. There is little content here of use.
* Move API principles from API_OVERVIEW.md to STYLE.md.
* Update some of the principles, in particular expressing client/server
directional neutrality and avoiding breaking changes that don't bring
major user facing wins.
* APIs should be human readable.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 6ca4644073da6d9930ba45d90d57d8c9b2062962
This patch introduces the tools/docs for a new flow for protoxform: freeze.
This performs a major version freeze and bump by modifying
package_version_status. Tooling now needs to deal with 3 possible versions (v2,
v3, v4alpha). The following contributions are made in the patch:
* Tooling added to support v2 APIs freeze, transitioning v3 to active and generating v4alpha.
* A new tool, merge_active_shadow.py, is introduced to combine hand-edited active v3 API protos with the v2 implied shadows for deprecated fields.
* The type database now spans v2 and v3 (and implied v4alpha files)
* api_proto_plugins can now take extra args on the Bazel CLI; this is used to plumb in the freeze arg to protoxform.
Docs are updated to reflect the v3 flow that developers should now
follow.
Part of #10355
This is the tools/docs component of #10601. See #10601 for the resulting
API protos generated by a freeze/fix cycle.
Risk level: Low (tooling only, no API changes yet)
Testing: new golden protos tests for protoxform, unit tests for merge_active_shadow.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ de222c3acf1fbf124ca44f50495fc4b8e9aba525
* Automatically derive active protos target used in proto_format.sh from the packages with files
annotated as active.
* Replace some sites with hardcoded v2/v3 with active/next_major_version_candidate.
* Move //docs:BUILD to //versioning:BUILD in API tree. This has already ceased to be used directly
in the docs build, so this makes things a bit clearer.
Risk level: Low (API tooling and build only)
Testing: fix_format (mostly idempotent)
Part of #10355.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4403003b9c0888ce81606a2f45fcc1da126514e7
Small update on proto_format path.
Signed-off-by: Dhi Aurrahman <dio@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ d78ad5b720e5a9a90304cd5c414772ad6afa88b5
This is the new style for indicating a file is WiP and subject to
breaking changes. Rather than rely on alpha major versions, which are
coarse grained and introduce migration difficulties for operators, we
use a file-level annotation.
Risk level: Low
Testing: API/docs build, manual inspection of docs.
Fixes#9769.
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
Co-authored-by: htuch <htuch@users.noreply.github.com>
Mirrored from https://github.com/envoyproxy/envoy @ 423fe76d5572bb4f1505391ccaaacf39b2bf2c85
Avoid deleting files without prompting, link back to the recommended extension API flow.
Risk level: Low
Testing: Manual
Fixes#9610
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 6ed1df2bdff19ada78f2253f931e68d9343eb398
In which we convert every v3alpha reference to v3. In future revs of the
stable API versioning policy, we will develop better tooling to support
> 2 alpha and stable versions. For v3, it seems reasonable to just mv
v3alpha to v3, since there should be no external consumers yet.
Risk level: Low
Testing: bazel test //test/..., CI.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5248a4fb7d4c2a3d1fa151f944d3a63f6b7a06cf
This captures the API versioning guidelines implied by
https://docs.google.com/document/d/1xeVvJ6KjFBkNjVspPbY_PwEDHC7XPi0J5p1SqUXcCl8/edit#heading=h.xgk8xel154p
and splits apart the Envoy API and internal implementation breaking change policies.
Some of the policy decisions (e.g. not allowing vNalpha to be hand edited, how we do manual breaking
changes, etc.) have been added to these guidelines based on recent experience with protoxform and
mechanical major version upgrade work, they are not part of the original stable API versioning work.
Risk level: Low
Testing: Formatting and docs build.
Fixes#8371
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 3801c6846a5c7bf4d230f1dad58985f2bb8bcdeb
We want to have just vN and vNalpha going forward as part of the v3
work.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 33511078f1f7e9cdd31b7a48b63f09de6afe46c6
* docs: more snapping fixes
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ c949a8144cf3b0162133dde0c489dea8a4078a47
As discussed in Slack, these should have been under api/config/filter/network
to begin with. Added a note to the style doc to make this clear in the
future.
*Risk level*: low (rename only)
*Testing*: existing tests suffice
*Doc Changes*: n/a
*Release Notes*: updated
Signed-off-by: Stephan Zuercher <stephan@turbinelabs.io>
Mirrored from https://github.com/envoyproxy/envoy @ 1dfde38343e7dfafe2c9f211229109bb22491257
1) Add ability to runtime filter to configure default, divisor, and
whether independent randomness is used.
2) Also add LE to the comparison filter.
Signed-off-by: Matt Klein <mklein@lyft.com>
There are several main changes in this PR:
Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos.
Create individual packages for each filter and add independent versioning to each filter.
Add visibility constraints to prevent formation of dependency cycles.
Add gogoproto annotations to improve go code generation.
After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package.
The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane).
Added a few gogoproto annotations to improve golang code generation.
Signed-off-by: Kuat Yessenov <kuat@google.com>
This is intended to capture some recent threads, it can grow as we learn
new lessons.
Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
* Fix format.
Signed-off-by: Harvey Tuch <htuch@google.com>
data-plane-api(Azure Pipelines)
Kuat
Matt Klein
htuch
Hong Zhang
Brian Pane