title: one line description
Title can be a one or two words to describe the subsystem or the aspect this PR applies to. Title and description must be lower case. For example:
- ci: update build image to 44d539cb
- docs: fix indent, buffer: add copyOut() method
- router:add x-envoy-overloaded header
- tls: add support for specifying TLS session ticket keys
Description:
What does this PR do? What was the behavior before the PR? What is the behavior with the PR? If fixing a bug, please describe what the original issue is and how the change resolves it. How does this feature get enabled? By default, config change, etc...
Risk Level: Low | Medium | High
Low: Small bug fix or small optional feature.
Medium: New features that are not enabled(for example: new filter). Small-medium features added to existing components(for example: modification to an existing filter).
High: Complicated changes such as flow control, rewrites of critical components, etc.
Note: The above is only a rough guide for choosing a level, please ask if you have any concerns about the risk of the PR.
Testing:
Explanation of what testing was done, for example: unit test, integration, manual testing, etc.
Note: It isn’t expected to do all forms of testing, please use your best judgement or ask for guidance if you are unsure. A good rule of thumb is the riskier the change, the more comprehensive the testing should be.
Docs Changes: Description of documentation changes. These should be made in docs/root and/or inline with the API protos. Please write in N/A if there were no documentation changes.
Release Notes:
If this change is user impacting you must add a release note to version_history.rst. Please include any relevant links. Each release note should be prefixed with the relevant subsystem in alphabetical order (see existing examples as a guide) and include links to relevant parts of the documentation. Thank you! Please write in N/A if there are no release notes.
[Optional Fixes #Issue]
[Optional Deprecated:]
Description of what is deprecated.