-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: mark matching API and related features as alpha #16210
Changes from 12 commits
7677de0
7f549fb
4a8325a
7c7b8d3
19d292b
1dc8ca4
57aa455
c5b2cd3
a4712bb
34290c9
4931d16
3684c37
7291160
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3,6 +3,11 @@ | |
Matching API | ||
============ | ||
|
||
.. attention:: | ||
|
||
The matching API is experimental and is currently under active development. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit: s/experimental/alpha/ |
||
Capabilities will be expanded over time and the configuration structures are likely to change. | ||
|
||
Envoy makes use of a :ref:`matching API <envoy_v3_api_msg_config.common.matcher.v3.Matcher>` | ||
to allow the various subsystems to express actions that should be performed based on incoming data. | ||
|
||
|
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -160,6 +160,12 @@ def format_comment_with_annotations(comment, type_name=''): | |
Returns: | ||
A string with additional RST from annotations. | ||
""" | ||
alpha_warning = '' | ||
if annotations.ALPHA_ANNOTATION in comment.annotations: | ||
experimental_warning = ( | ||
'.. warning::\n This API is alpha and is not covered by the :ref:`threat model <arch_overview_threat_model>`.\n\n' | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. FWIW, we have a broader issue which we can resolve after we land this PR. We have both implementation and API alpha/experimental/unknown robustness status. An API is not really insecure in and of itself, this is an implementation attribute. We really need a way to mark in the protos client specific implementation status details, since Envoy vs. gRPC support for a feature might have different implementation status. I started to explore this in #11085, but it's not really something I have b/w for. Maybe @phlax this can be part of the docs/tooling roadmap? CC @markdroth There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree, it would be nice to have some generic solution for this kind of thing. Matt has been saying for a while that we need a way to have client-specific docs in the proto files, not just for API status but for any type of documentation. Although as the number of xDS clients grows, I'm not sure how feasible it will be to document all of the in the same proto files. But this is definitely something we need to come up with a good strategy for. |
||
) | ||
|
||
formatted_extension = '' | ||
if annotations.EXTENSION_ANNOTATION in comment.annotations: | ||
extension = comment.annotations[annotations.EXTENSION_ANNOTATION] | ||
|
@@ -169,7 +175,7 @@ def format_comment_with_annotations(comment, type_name=''): | |
for category in comment.annotations[annotations.EXTENSION_CATEGORY_ANNOTATION].split(","): | ||
formatted_extension_category += format_extension_category(category) | ||
comment = annotations.without_annotations(strip_leading_space(comment.raw) + '\n') | ||
return comment + formatted_extension + formatted_extension_category | ||
return alpha_warning + comment + formatted_extension + formatted_extension_category | ||
|
||
|
||
def map_lines(f, s): | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to update this comment given it's now alpha tagging :-)
I think also worth calling out that things tagged alpha are not yet subject to the stable API policies and security release policies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm we still have extension level alpha tagging which differs from this alpha tag which is the only way to mark messages within core as alpha. What kind of change were you thinking about?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was trying to resolve the two, and have alpha tagging for extensions be functionally the same as alpha tagging for messages and fields, which is basically that both are WIP, not stable APIs and less trusted code.