diff --git a/.azure-pipelines/pipelines.yml b/.azure-pipelines/pipelines.yml index e60c04242b8d8..4babd9df8d0d6 100644 --- a/.azure-pipelines/pipelines.yml +++ b/.azure-pipelines/pipelines.yml @@ -1,7 +1,7 @@ trigger: branches: include: - - "master" + - "main" - "release/v*" tags: include: @@ -53,6 +53,7 @@ stages: - script: ci/run_envoy_docker.sh 'ci/do_ci.sh docs' workingDirectory: $(Build.SourcesDirectory) env: + AZP_BRANCH: $(Build.SourceBranch) ENVOY_DOCKER_BUILD_DIR: $(Build.StagingDirectory) BAZEL_REMOTE_CACHE: grpcs://remotebuildexecution.googleapis.com BAZEL_REMOTE_INSTANCE: projects/envoy-ci/instances/default_instance diff --git a/.bazelrc b/.bazelrc index 19d36e85dcd6d..e803393295fcd 100644 --- a/.bazelrc +++ b/.bazelrc @@ -227,7 +227,7 @@ build:remote-clang-cl --config=clang-cl build:remote-clang-cl --config=rbe-toolchain-clang-cl # Docker sandbox -# NOTE: Update this from https://github.com/envoyproxy/envoy-build-tools/blob/master/toolchains/rbe_toolchains_config.bzl#L8 +# NOTE: Update this from https://github.com/envoyproxy/envoy-build-tools/blob/main/toolchains/rbe_toolchains_config.bzl#L8 build:docker-sandbox --experimental_docker_image=envoyproxy/envoy-build-ubuntu:b480535e8423b5fd7c102fd30c92f4785519e33a build:docker-sandbox --spawn_strategy=docker build:docker-sandbox --strategy=Javac=docker diff --git a/.github/ISSUE_TEMPLATE/non--crash-security--bug.md b/.github/ISSUE_TEMPLATE/non--crash-security--bug.md index 15c784680ecfc..5b80df378a022 100644 --- a/.github/ISSUE_TEMPLATE/non--crash-security--bug.md +++ b/.github/ISSUE_TEMPLATE/non--crash-security--bug.md @@ -22,7 +22,7 @@ returned, etc. > Include sample requests, environment, etc. All data and inputs required to reproduce the bug. ->**Note**: The [Envoy_collect tool](https://github.com/envoyproxy/envoy/blob/master/tools/envoy_collect/README.md) +>**Note**: The [Envoy_collect tool](https://github.com/envoyproxy/envoy/blob/main/tools/envoy_collect/README.md) gathers a tarball with debug logs, config and the following admin endpoints: /stats, /clusters and /server_info. Please note if there are privacy concerns, sanitize the data prior to sharing the tarball/pasting. @@ -46,4 +46,4 @@ sharing. *Call Stack*: > If the Envoy binary is crashing, a call stack is **required**. -Please refer to the [Bazel Stack trace documentation](https://github.com/envoyproxy/envoy/tree/master/bazel#stack-trace-symbol-resolution). +Please refer to the [Bazel Stack trace documentation](https://github.com/envoyproxy/envoy/tree/main/bazel#stack-trace-symbol-resolution). diff --git a/.github/workflows/codeql-push.yml b/.github/workflows/codeql-push.yml index d6110bbddca2c..fbe091a90ec00 100644 --- a/.github/workflows/codeql-push.yml +++ b/.github/workflows/codeql-push.yml @@ -24,7 +24,9 @@ jobs: - name: Get build targets run: | . .github/workflows/get_build_targets.sh - echo ::set-env name=BUILD_TARGETS::$(echo $BUILD_TARGETS_LOCAL) + echo 'BUILD_TARGETS<> $GITHUB_ENV + echo $BUILD_TARGETS_LOCAL >> $GITHUB_ENV + echo 'EOF' >> $GITHUB_ENV # If this run was triggered by a pull request event, then checkout # the head of the pull request instead of the merge commit. - run: git checkout HEAD^2 diff --git a/.github/workflows/get_build_targets.sh b/.github/workflows/get_build_targets.sh index c8d63b8dad8c1..180ec67040b1e 100755 --- a/.github/workflows/get_build_targets.sh +++ b/.github/workflows/get_build_targets.sh @@ -6,7 +6,7 @@ readonly SEARCH_FOLDER="//source/common/..." set -e -o pipefail function get_targets() { - # Comparing the PR HEAD with the upstream master HEAD. + # Comparing the PR HEAD with the upstream main HEAD. git diff --name-only HEAD FETCH_HEAD | while IFS= read -r line do # Only targets under those folders. @@ -23,6 +23,6 @@ function get_targets() { } # Fetching the upstream HEAD to compare with and stored in FETCH_HEAD. -git fetch https://github.com/envoyproxy/envoy.git master 2>/dev/null +git fetch https://github.com/envoyproxy/envoy.git main 2>/dev/null export BUILD_TARGETS_LOCAL=$(echo $(get_targets)) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1bef2955c288e..03eda5c52f071 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -47,7 +47,7 @@ versioning guidelines: * Features may be marked as deprecated in a given versioned API at any point in time, but this may only be done when a replacement implementation and configuration path is available in Envoy on - master. Deprecators must implement a conversion from the deprecated configuration to the latest + main. Deprecators must implement a conversion from the deprecated configuration to the latest `vNalpha` (with the deprecated field) that Envoy uses internally. A field may be deprecated if this tool would be able to perform the conversion. For example, removing a field to describe HTTP/2 window settings is valid if a more comprehensive HTTP/2 protocol options field is being @@ -72,7 +72,7 @@ versioning guidelines: config ([example](configs/using_deprecated_config.v2.yaml)). Finally, following the deprecation of the API major version where the field was first marked deprecated, the entire implementation code will be removed from the Envoy implementation. -* This policy means that organizations deploying master should have some time to get ready for +* This policy means that organizations deploying main should have some time to get ready for breaking changes at the next major API version. This is typically a window of at least 12 months or until the organization moves to the next major API version. * The breaking change policy also applies to source level extensions (e.g., filters). Code that @@ -143,7 +143,7 @@ versioning guidelines: * If your PR involves any changes to [envoy-filter-example](https://github.com/envoyproxy/envoy-filter-example) (for example making a new branch so that CI can pass) it is your responsibility to follow through with merging those - changes back to master once the CI dance is done. + changes back to main once the CI dance is done. * If your PR is a high risk change, the reviewer may ask that you runtime guard it. See the section on runtime guarding below. @@ -188,18 +188,18 @@ maintainer's discretion. Generally all runtime guarded features will be set true release is cut. Old code paths for refactors can be cleaned up after a release and there has been some production run time. Old code for behavioral changes will be deprecated after six months. Runtime features are set true by default by inclusion in -[source/common/runtime/runtime_features.cc](https://github.com/envoyproxy/envoy/blob/master/source/common/runtime/runtime_features.cc) +[source/common/runtime/runtime_features.cc](https://github.com/envoyproxy/envoy/blob/main/source/common/runtime/runtime_features.cc) There are four suggested options for testing new runtime features: -1. Create a per-test Runtime::LoaderSingleton as done in [DeprecatedFieldsTest.IndividualFieldDisallowedWithRuntimeOverride](https://github.com/envoyproxy/envoy/blob/master/test/common/protobuf/utility_test.cc) +1. Create a per-test Runtime::LoaderSingleton as done in [DeprecatedFieldsTest.IndividualFieldDisallowedWithRuntimeOverride](https://github.com/envoyproxy/envoy/blob/main/test/common/protobuf/utility_test.cc) 2. Create a [parameterized test](https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#how-to-write-value-parameterized-tests) where the set up of the test sets the new runtime value explicitly to GetParam() as outlined in (1). 3. Set up integration tests with custom runtime defaults as documented in the - [integration test README](https://github.com/envoyproxy/envoy/blob/master/test/integration/README.md) + [integration test README](https://github.com/envoyproxy/envoy/blob/main/test/integration/README.md) 4. Run a given unit test with the new runtime value explicitly set true or false as done - for [runtime_flag_override_test](https://github.com/envoyproxy/envoy/blob/master/test/common/runtime/BUILD) + for [runtime_flag_override_test](https://github.com/envoyproxy/envoy/blob/main/test/common/runtime/BUILD) Runtime code is held to the same standard as regular Envoy code, so both the old path and the new should have 100% coverage both with the feature defaulting true diff --git a/DEPENDENCY_POLICY.md b/DEPENDENCY_POLICY.md index 4101e9bed9daf..c17acd4347ba0 100644 --- a/DEPENDENCY_POLICY.md +++ b/DEPENDENCY_POLICY.md @@ -40,7 +40,7 @@ Dependency declarations must: and `urls` to reference the version. If you need to reference version `X.Y.Z` as `X_Y_Z`, this may appear in a string as `{underscore_version}`, similarly for `X-Y-Z` you can use `{dash_version}`. -* Versions should prefer release versions over master branch GitHub SHA tarballs. A comment is +* Versions should prefer release versions over main branch GitHub SHA tarballs. A comment is necessary if the latter is used. This comment should contain the reason that a non-release version is being used. * Provide accurate entries for `use_category`. Please think carefully about whether there are data @@ -94,7 +94,7 @@ basis: * Extension [CODEOWNERS](CODEOWNERS) should update extension specific dependencies. -Where possible, we prefer the latest release version for external dependencies, rather than master +Where possible, we prefer the latest release version for external dependencies, rather than main branch GitHub SHA tarballs. ## Dependency patches diff --git a/DEVELOPER.md b/DEVELOPER.md index 465644c0e02ce..a3bc00b1a067c 100644 --- a/DEVELOPER.md +++ b/DEVELOPER.md @@ -1,38 +1,37 @@ # Developer documentation -Envoy is built using the Bazel build system. CircleCI builds, tests, and runs coverage against all pull requests and the master branch. +Envoy is built using the Bazel build system. CircleCI builds, tests, and runs coverage against all pull requests and the main branch. -To get started building Envoy locally, see the [Bazel quick start](https://github.com/envoyproxy/envoy/blob/master/bazel/README.md#quick-start-bazel-build-for-developers). -To run tests, there are Bazel [targets](https://github.com/envoyproxy/envoy/blob/master/bazel/README.md#testing-envoy-with-bazel) for Google Test. -To generate a coverage report, there is a [coverage build script](https://github.com/envoyproxy/envoy/blob/master/bazel/README.md#coverage-builds). +To get started building Envoy locally, see the [Bazel quick start](https://github.com/envoyproxy/envoy/blob/main/bazel/README.md#quick-start-bazel-build-for-developers). +To run tests, there are Bazel [targets](https://github.com/envoyproxy/envoy/blob/main/bazel/README.md#testing-envoy-with-bazel) for Google Test. +To generate a coverage report, there is a [coverage build script](https://github.com/envoyproxy/envoy/blob/main/bazel/README.md#coverage-builds). -If you plan to contribute to Envoy, you may find it useful to install the Envoy [development support toolchain](https://github.com/envoyproxy/envoy/blob/master/support/README.md), which helps automate parts of the development process, particularly those involving code review. +If you plan to contribute to Envoy, you may find it useful to install the Envoy [development support toolchain](https://github.com/envoyproxy/envoy/blob/main/support/README.md), which helps automate parts of the development process, particularly those involving code review. Below is a list of additional documentation to aid the development process: - [General build and installation documentation](https://www.envoyproxy.io/docs/envoy/latest/install/install) -- [Building and testing Envoy with Bazel](https://github.com/envoyproxy/envoy/blob/master/bazel/README.md) +- [Building and testing Envoy with Bazel](https://github.com/envoyproxy/envoy/blob/main/bazel/README.md) -- [Managing external dependencies with Bazel](https://github.com/envoyproxy/envoy/blob/master/bazel/EXTERNAL_DEPS.md) +- [Managing external dependencies with Bazel](https://github.com/envoyproxy/envoy/blob/main/bazel/EXTERNAL_DEPS.md) -- [Guide to Envoy Bazel rules (managing `BUILD` files)](https://github.com/envoyproxy/envoy/blob/master/bazel/DEVELOPER.md) +- [Guide to Envoy Bazel rules (managing `BUILD` files)](https://github.com/envoyproxy/envoy/blob/main/bazel/DEVELOPER.md) -- [Using Docker for building and testing](https://github.com/envoyproxy/envoy/tree/master/ci) +- [Using Docker for building and testing](https://github.com/envoyproxy/envoy/tree/main/ci) -- [Guide to contributing to Envoy](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md) +- [Guide to contributing to Envoy](https://github.com/envoyproxy/envoy/blob/main/CONTRIBUTING.md) -- [Overview of Envoy's testing frameworks](https://github.com/envoyproxy/envoy/blob/master/test/README.md) +- [Overview of Envoy's testing frameworks](https://github.com/envoyproxy/envoy/blob/main/test/README.md) -- [Overview of how to write integration tests for new code](https://github.com/envoyproxy/envoy/blob/master/test/integration/README.md) +- [Overview of how to write integration tests for new code](https://github.com/envoyproxy/envoy/blob/main/test/integration/README.md) - [Envoy filter example project (how to consume and extend Envoy as a submodule)](https://github.com/envoyproxy/envoy-filter-example) -- [Performance testing Envoy with `tcmalloc`/`pprof`](https://github.com/envoyproxy/envoy/blob/master/bazel/PPROF.md) +- [Performance testing Envoy with `tcmalloc`/`pprof`](https://github.com/envoyproxy/envoy/blob/main/bazel/PPROF.md) And some documents on components of Envoy architecture: -- [Envoy flow control](https://github.com/envoyproxy/envoy/blob/master/source/docs/flow_control.md) - -- [Envoy's subset load balancer](https://github.com/envoyproxy/envoy/blob/master/source/docs/subset_load_balancer.md) +- [Envoy flow control](https://github.com/envoyproxy/envoy/blob/main/source/docs/flow_control.md) +- [Envoy's subset load balancer](https://github.com/envoyproxy/envoy/blob/main/source/docs/subset_load_balancer.md) diff --git a/EXTENSION_POLICY.md b/EXTENSION_POLICY.md index 0063a2a2139c4..24503c44c042b 100644 --- a/EXTENSION_POLICY.md +++ b/EXTENSION_POLICY.md @@ -15,7 +15,7 @@ The following procedure will be used when proposing new extensions for inclusion 2. All extensions must be sponsored by an existing maintainer. Sponsorship means that the maintainer will shepherd the extension through design/code reviews. Maintainers can self-sponsor extensions if they are going to write them, shepherd them, and maintain them. - + Sponsorship serves two purposes: * It ensures that the extension will ultimately meet the Envoy quality bar. * It makes sure that incentives are aligned and that extensions are not added to the repo without @@ -24,7 +24,7 @@ The following procedure will be used when proposing new extensions for inclusion *If sponsorship cannot be found from an existing maintainer, an organization can consider [doing the work to become a maintainer](./GOVERNANCE.md#process-for-becoming-a-maintainer) in order to be able to self-sponsor extensions.* - + 3. Each extension must have two reviewers proposed for reviewing PRs to the extension. Neither of the reviewers must be a senior maintainer. Existing maintainers (including the sponsor) and other contributors can count towards this number. The initial reviewers will be codified in the @@ -88,7 +88,7 @@ The `security_posture` is one of: * `unknown`: This is functionally equivalent to `requires_trusted_downstream_and_upstream`, but acts as a placeholder to allow us to identify extensions that need classifying. * `data_plane_agnostic`: Not relevant to data plane threats, e.g. stats sinks. - + An assessment of a robust security posture for an extension is subject to the following guidelines: * Does the extension have fuzz coverage? If it's only receiving fuzzing @@ -105,7 +105,7 @@ An assessment of a robust security posture for an extension is subject to the fo * Does the extension have active [CODEOWNERS](CODEOWNERS) who are willing to vouch for the robustness of the extension? * Is the extension absent a [low coverage - exception](https://github.com/envoyproxy/envoy/blob/master/test/per_file_coverage.sh#L5)? + exception](https://github.com/envoyproxy/envoy/blob/main/test/per_file_coverage.sh#L5)? The current stability and security posture of all extensions can be seen [here](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/threat_model#core-and-extensions). diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 767605eda2205..83b076adfbf8a 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -38,7 +38,7 @@ The areas of specialization listed in [OWNERS.md](OWNERS.md) can be used to help with routing an issue/question to the right person. * Triage build issues - file issues for known flaky builds or bugs, and either fix or find someone - to fix any master build breakages. + to fix any main build breakages. * During GitHub issue triage, apply all applicable [labels](https://github.com/envoyproxy/envoy/labels) to each new issue. Labels are extremely useful for future issue follow up. Which labels to apply is somewhat subjective so just use your best judgment. A few of the most important labels that are @@ -77,7 +77,7 @@ or you can subscribe to the iCal feed [here](webcal://kubernetes.app.opsgenie.co "is:open is:issue milestone:[current milestone]" and either hold off until they are fixed or bump them to the next milestone. * Begin marshalling the ongoing PR flow in this repo. Ask maintainers to hold off merging any - particularly risky PRs until after the release is tagged. This is because we aim for master to be + particularly risky PRs until after the release is tagged. This is because we aim for main to be at release candidate quality at all times. * Do a final check of the [release notes](docs/root/version_history/current.rst): * Make any needed corrections (grammar, punctuation, formatting, etc.). @@ -89,7 +89,7 @@ or you can subscribe to the iCal feed [here](webcal://kubernetes.app.opsgenie.co "1.6.0". * Update the [RELEASES](RELEASES.md) doc with the relevant dates. * Get a review and merge. -* Wait for tests to pass on [master](https://dev.azure.com/cncf/envoy/_build). +* Wait for tests to pass on [main](https://dev.azure.com/cncf/envoy/_build). * Create a [tagged release](https://github.com/envoyproxy/envoy/releases). The release should start with "v" and be followed by the version number. E.g., "v1.6.0". **This must match the [VERSION](VERSION).** @@ -104,7 +104,7 @@ or you can subscribe to the iCal feed [here](webcal://kubernetes.app.opsgenie.co * Make sure we tweet the new release: either have Matt do it or email social@cncf.io and ask them to do an Envoy account post. * Do a new PR to setup the next version - * Update [VERSION](VERSION) to the next development release. E.g., "1.7.0-dev". + * Update [VERSION](VERSION) to the next development release. E.g., "1.7.0-dev". * `git mv docs/root/version_history/current.rst docs/root/version_history/v1.6.0.rst`, filling in the previous release version number in the filename, and add an entry for the new file in the `toctree` in [version_history.rst](docs/root/version_history/version_history.rst). diff --git a/PULL_REQUEST_TEMPLATE.md b/PULL_REQUEST_TEMPLATE.md index 5a1545aacd7a1..083ea68ea7402 100644 --- a/PULL_REQUEST_TEMPLATE.md +++ b/PULL_REQUEST_TEMPLATE.md @@ -10,7 +10,7 @@ Thank you in advance for helping to keep Envoy secure. --> For an explanation of how to fill out the fields, please see the relevant section -in [PULL_REQUESTS.md](https://github.com/envoyproxy/envoy/blob/master/PULL_REQUESTS.md) +in [PULL_REQUESTS.md](https://github.com/envoyproxy/envoy/blob/main/PULL_REQUESTS.md) Commit Message: Additional Description: diff --git a/README.md b/README.md index 3705c4e5bd55b..84697256efd1a 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -![Envoy Logo](https://github.com/envoyproxy/artwork/blob/master/PNG/Envoy_Logo_Final_PANTONE.png) +![Envoy Logo](https://github.com/envoyproxy/artwork/blob/main/PNG/Envoy_Logo_Final_PANTONE.png) [Cloud-native high-performance edge/middle/service proxy](https://www.envoyproxy.io/) @@ -66,7 +66,7 @@ have prior experience. To get started: * [Beginner issues](https://github.com/envoyproxy/envoy/issues?q=is%3Aopen+is%3Aissue+label%3Abeginner) * [Build/test quick start using docker](ci#building-and-running-tests-as-a-developer) * [Developer guide](DEVELOPER.md) -* Consider installing the Envoy [development support toolchain](https://github.com/envoyproxy/envoy/blob/master/support/README.md), which helps automate parts of the development process, particularly those involving code review. +* Consider installing the Envoy [development support toolchain](https://github.com/envoyproxy/envoy/blob/main/support/README.md), which helps automate parts of the development process, particularly those involving code review. * Please make sure that you let us know if you are working on an issue so we don't duplicate work! ## Community Meeting diff --git a/RELEASES.md b/RELEASES.md index 0a58aa22c4c28..b32e815c63cb1 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -2,7 +2,7 @@ ## Active development -Active development is happening on the `master` branch, and a new version is released from it +Active development is happening on the `main` branch, and a new version is released from it at the end of each quarter. ## Stable releases @@ -10,23 +10,23 @@ at the end of each quarter. Stable releases of Envoy include: * Extended maintenance window (any version released in the last 12 months). -* Security fixes backported from the `master` branch (including those deemed not worthy +* Security fixes backported from the `main` branch (including those deemed not worthy of creating a CVE). -* Stability fixes backported from the `master` branch (anything that can result in a crash, +* Stability fixes backported from the `main` branch (anything that can result in a crash, including crashes triggered by a trusted control plane). * Bugfixes, deemed worthwhile by the maintainers of stable releases. ### Hand-off Hand-off to the maintainers of stable releases happens after Envoy maintainers release a new -version from the `master` branch by creating a `vX.Y.0` tag and a corresponding `release/vX.Y` +version from the `main` branch by creating a `vX.Y.0` tag and a corresponding `release/vX.Y` branch, with merge permissions given to the release manager of stable releases, and CI configured to execute tests on it. ### Security releases Critical security fixes are owned by the Envoy security team, which provides fixes for the -`master` branch, and the latest release branch. Once those fixes are ready, the maintainers +`main` branch, and the latest release branch. Once those fixes are ready, the maintainers of stable releases backport them to the remaining supported stable releases. ### Backports @@ -37,7 +37,7 @@ by adding the `backport/review` or `backport/approved` label (this can be done u `/backport` command). Changes nominated by the change author and/or members of the Envoy community are evaluated for backporting on a case-by-case basis, and require approval from either the release manager of stable release, Envoy maintainers, or Envoy security team. Once approved, those fixes -are backported from the `master` branch to all supported stable branches by the maintainers of +are backported from the `main` branch to all supported stable branches by the maintainers of stable releases. New stable versions from non-critical security fixes are released on a regular schedule, initially aiming for the bi-weekly releases. diff --git a/SECURITY.md b/SECURITY.md index 34138877e6b30..53b4de82b7802 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -63,31 +63,31 @@ score >= 4; see below). If the fix relies on another upstream project's disclosu will adjust the process as well. We will work with the upstream project to fit their timeline and best protect our users. -### Released versions and master branch +### Released versions and main branch If the vulnerability affects the last point release version, e.g. 1.10, then the full security release process described in this document will be activated. A security point release will be -created for 1.10, e.g. 1.10.1, together with a fix to master if necessary. Older point releases, +created for 1.10, e.g. 1.10.1, together with a fix to main if necessary. Older point releases, e.g. 1.9, are not supported by the Envoy project and will not have any security release created. -If a security vulnerability affects only these older versions but not master or the last supported +If a security vulnerability affects only these older versions but not main or the last supported point release, the Envoy security team will share this information with the private distributor list, following the standard embargo process, but not create a security release. After the embargo expires, the vulnerability will be described as a GitHub issue. A CVE will be filed if warranted by severity. -If a vulnerability does not affect any point release but only master, additional caveats apply: +If a vulnerability does not affect any point release but only main, additional caveats apply: * If the issue is detected and a fix is available within 7 days of the introduction of the vulnerability, or the issue is deemed a low severity vulnerability by the Envoy maintainer and - security teams, the fix will be publicly reviewed and landed on master. If the severity is at least + security teams, the fix will be publicly reviewed and landed on main. If the severity is at least medium or at maintainer discretion a courtesy e-mail will be sent to envoy-users@googlegroups.com, envoy-dev@googlegroups.com, envoy-security-announce@googlegroups.com and cncf-envoy-distributors-announce@lists.cncf.io. * If the vulnerability has been in existence for more than 7 days and is medium or higher, we will activate the security release process. -We advise distributors and operators working from the master branch to allow at least 5 days soak +We advise distributors and operators working from the main branch to allow at least 5 days soak time after cutting a binary release before distribution or rollout, to allow time for our fuzzers to detect issues during their execution on ClusterFuzz. A soak period of 7 days provides an even stronger guarantee, since we will invoke the security release process for medium or higher severity issues @@ -181,7 +181,7 @@ patches, understand exact mitigation steps, etc. should be reserved for remotely exploitable or privilege escalation issues. Otherwise, this process can be skipped. - The Fix Lead will email the patches to cncf-envoy-distributors-announce@lists.cncf.io so - distributors can prepare builds to be available to users on the day of the issue's announcement. Any + distributors can prepare builds to be available to users on the day of the issue's announcement. Any patches against main will be updated and resent weekly. Distributors should read about the [Private Distributors List](#private-distributors-list) to find out the requirements for being added to this list. @@ -193,7 +193,7 @@ patches, understand exact mitigation steps, etc. - The maintainers will create a new patch release branch from the latest patch release tag + the fix from the security branch. As a practical example if v1.5.3 is the latest patch release in Envoy.git a new branch will be created called v1.5.4 which includes only patches required to fix the issue. -- The Fix Lead will cherry-pick the patches onto the master branch and all relevant release branches. +- The Fix Lead will cherry-pick the patches onto the main branch and all relevant release branches. The Fix Team will LGTM and merge. Maintainers will merge these PRs as quickly as possible. Changes shouldn't be made to the commits even for a typo in the CHANGELOG as this will change the git sha of the commits leading to confusion and potentially conflicts as the fix is cherry-picked around diff --git a/api/API_VERSIONING.md b/api/API_VERSIONING.md index 25e80aaa8407d..c045e7d5ce4e4 100644 --- a/api/API_VERSIONING.md +++ b/api/API_VERSIONING.md @@ -102,7 +102,7 @@ Envoy will support at most three major versions of any API package at all times: for the next stable major version. This is only generated when the current stable major version requires a breaking change at the next cycle, e.g. a deprecation or field rename. This release candidate is mechanically generated via the - [protoxform](https://github.com/envoyproxy/envoy/tree/master/tools/protoxform) tool from the + [protoxform](https://github.com/envoyproxy/envoy/tree/main/tools/protoxform) tool from the current stable major version, making use of annotations such as `deprecated = true`. This is not a human editable artifact. @@ -158,7 +158,7 @@ methods, depending on whether the change is mechanical or manual. ## Mechanical breaking changes Field deprecations, renames, etc. are mechanical changes that are supported by the -[protoxform](https://github.com/envoyproxy/envoy/tree/master/tools/protoxform) tool. These are +[protoxform](https://github.com/envoyproxy/envoy/tree/main/tools/protoxform) tool. These are guided by [annotations](STYLE.md#api-annotations). ## Manual breaking changes diff --git a/api/CONTRIBUTING.md b/api/CONTRIBUTING.md index 773248f2e2ea6..01d7da43e9fdc 100644 --- a/api/CONTRIBUTING.md +++ b/api/CONTRIBUTING.md @@ -9,7 +9,7 @@ changes. They may be as part of a larger implementation PR. Please follow the st process for validating build/test sanity of `api/` before submitting a PR. *Note: New .proto files should be added to -[BUILD](https://github.com/envoyproxy/envoy/blob/master/api/versioning/BUILD) in order to get the RSTs generated.* +[BUILD](https://github.com/envoyproxy/envoy/blob/main/api/versioning/BUILD) in order to get the RSTs generated.* ## Documentation changes diff --git a/api/README.md b/api/README.md index 95f49ba58e4dd..6e899513e8d6f 100644 --- a/api/README.md +++ b/api/README.md @@ -9,9 +9,9 @@ blog post for more information on the universal data plane concept. # Repository structure The API tree can be found at two locations: -* https://github.com/envoyproxy/envoy/tree/master/api - canonical read/write home for the APIs. +* https://github.com/envoyproxy/envoy/tree/main/api - canonical read/write home for the APIs. * https://github.com/envoyproxy/data-plane-api - read-only mirror of - https://github.com/envoyproxy/envoy/tree/master/api, providing the ability to consume the data + https://github.com/envoyproxy/envoy/tree/main/api, providing the ability to consume the data plane APIs without the Envoy implementation. # Further API reading diff --git a/api/envoy/api/v2/core/protocol.proto b/api/envoy/api/v2/core/protocol.proto index 9c47e388ee1af..ae1a86424cf07 100644 --- a/api/envoy/api/v2/core/protocol.proto +++ b/api/envoy/api/v2/core/protocol.proto @@ -201,7 +201,7 @@ message Http2ProtocolOptions { // Still under implementation. DO NOT USE. // // Allows metadata. See [metadata - // docs](https://github.com/envoyproxy/envoy/blob/master/source/docs/h2_metadata.md) for more + // docs](https://github.com/envoyproxy/envoy/blob/main/source/docs/h2_metadata.md) for more // information. bool allow_metadata = 6; diff --git a/api/envoy/config/core/v3/protocol.proto b/api/envoy/config/core/v3/protocol.proto index 17a6955d6851c..cb3179fd50aec 100644 --- a/api/envoy/config/core/v3/protocol.proto +++ b/api/envoy/config/core/v3/protocol.proto @@ -262,7 +262,7 @@ message Http2ProtocolOptions { // Still under implementation. DO NOT USE. // // Allows metadata. See [metadata - // docs](https://github.com/envoyproxy/envoy/blob/master/source/docs/h2_metadata.md) for more + // docs](https://github.com/envoyproxy/envoy/blob/main/source/docs/h2_metadata.md) for more // information. bool allow_metadata = 6; diff --git a/api/envoy/config/core/v4alpha/protocol.proto b/api/envoy/config/core/v4alpha/protocol.proto index 807488cef49d8..aad7fbf47d393 100644 --- a/api/envoy/config/core/v4alpha/protocol.proto +++ b/api/envoy/config/core/v4alpha/protocol.proto @@ -269,7 +269,7 @@ message Http2ProtocolOptions { // Still under implementation. DO NOT USE. // // Allows metadata. See [metadata - // docs](https://github.com/envoyproxy/envoy/blob/master/source/docs/h2_metadata.md) for more + // docs](https://github.com/envoyproxy/envoy/blob/main/source/docs/h2_metadata.md) for more // information. bool allow_metadata = 6; diff --git a/bazel/EXTERNAL_DEPS.md b/bazel/EXTERNAL_DEPS.md index 4f66ef80eac8b..02ba28e30674a 100644 --- a/bazel/EXTERNAL_DEPS.md +++ b/bazel/EXTERNAL_DEPS.md @@ -78,7 +78,7 @@ documentation for further references. # Updating an external dependency version 1. Update the corresponding entry in -[the repository locations file.](https://github.com/envoyproxy/envoy/blob/master/bazel/repository_locations.bzl) +[the repository locations file.](https://github.com/envoyproxy/envoy/blob/main/bazel/repository_locations.bzl) 2. `bazel test //test/...` # Overriding an external dependency temporarily @@ -88,7 +88,7 @@ specifying Bazel option [`--override_repository`](https://docs.bazel.build/versions/master/command-line-reference.html) to point to a local copy. The option can used multiple times to override multiple dependencies. The name of the dependency can be found in -[the repository locations file.](https://github.com/envoyproxy/envoy/blob/master/bazel/repository_locations.bzl) +[the repository locations file.](https://github.com/envoyproxy/envoy/blob/main/bazel/repository_locations.bzl) The path of the local copy has to be absolute path. For repositories built by `envoy_cmake_external()` in `bazel/foreign_cc/BUILD`, diff --git a/bazel/PPROF.md b/bazel/PPROF.md index 97e1c0541181d..689520a11c0b3 100644 --- a/bazel/PPROF.md +++ b/bazel/PPROF.md @@ -8,7 +8,7 @@ specific place yourself. Static linking is already available (because of a `HeapProfilerDump()` call inside -[`Envoy::Profiler::Heap::stopProfiler())`](https://github.com/envoyproxy/envoy/blob/master/source/common/profiler/profiler.cc#L32-L39)). +[`Envoy::Profiler::Heap::stopProfiler())`](https://github.com/envoyproxy/envoy/blob/main/source/common/profiler/profiler.cc#L32-L39)). ### Compiling a statically-linked Envoy @@ -61,7 +61,7 @@ is controlled by `ProfilerStart()`/`ProfilerStop()`, and the [Gperftools Heap Profiler](https://gperftools.github.io/gperftools/heapprofile.html) is controlled by `HeapProfilerStart()`, `HeapProfilerStop()` and `HeapProfilerDump()`. -These functions are wrapped by Envoy objects defined in [`source/common/profiler/profiler.h`](https://github.com/envoyproxy/envoy/blob/master/source/common/profiler/profiler.h)). +These functions are wrapped by Envoy objects defined in [`source/common/profiler/profiler.h`](https://github.com/envoyproxy/envoy/blob/main/source/common/profiler/profiler.h)). To enable profiling programmatically: diff --git a/bazel/README.md b/bazel/README.md index 36e8f7ebc3247..59f6d466f6011 100644 --- a/bazel/README.md +++ b/bazel/README.md @@ -40,13 +40,13 @@ independently sourced, the following steps should be followed: This section describes how to and what dependencies to install to get started building Envoy with Bazel. If you would rather use a pre-build Docker image with required tools installed, skip to [this section](#building-envoy-with-the-ci-docker-image). -As a developer convenience, a [WORKSPACE](https://github.com/envoyproxy/envoy/blob/master/WORKSPACE) and +As a developer convenience, a [WORKSPACE](https://github.com/envoyproxy/envoy/blob/main/WORKSPACE) and [rules for building a recent -version](https://github.com/envoyproxy/envoy/blob/master/bazel/repositories.bzl) of the various Envoy +version](https://github.com/envoyproxy/envoy/blob/main/bazel/repositories.bzl) of the various Envoy dependencies are provided. These are provided as is, they are only suitable for development and testing purposes. The specific versions of the Envoy dependencies used in this build may not be up-to-date with the latest security patches. See -[this doc](https://github.com/envoyproxy/envoy/blob/master/bazel/EXTERNAL_DEPS.md#updating-an-external-dependency-version) +[this doc](https://github.com/envoyproxy/envoy/blob/main/bazel/EXTERNAL_DEPS.md#updating-an-external-dependency-version) for how to update or override dependencies. 1. Install external dependencies. @@ -239,7 +239,7 @@ MSYS2 or Git bash), run: ./ci/run_envoy_docker.sh './ci/windows_ci_steps.sh' ``` -See also the [documentation](https://github.com/envoyproxy/envoy/tree/master/ci) for developer use of the +See also the [documentation](https://github.com/envoyproxy/envoy/tree/main/ci) for developer use of the CI Docker image. ## Building Envoy with Remote Execution @@ -331,7 +331,7 @@ bazel test //test/... An individual test target can be run with a more specific Bazel [label](https://bazel.build/versions/master/docs/build-ref.html#Labels), e.g. to build and run only the units tests in -[test/common/http/async_client_impl_test.cc](https://github.com/envoyproxy/envoy/blob/master/test/common/http/async_client_impl_test.cc): +[test/common/http/async_client_impl_test.cc](https://github.com/envoyproxy/envoy/blob/main/test/common/http/async_client_impl_test.cc): ``` bazel test //test/common/http:async_client_impl_test @@ -730,8 +730,8 @@ need to navigate down and open "coverage.html" but then you can navigate per nor have seen some issues with seeing the artifacts tab. If you can't see it, log out of Circle, and then log back in and it should start working. -The latest coverage report for master is available -[here](https://storage.googleapis.com/envoy-postsubmit/master/coverage/index.html). The latest fuzz coverage report for master is available [here](https://storage.googleapis.com/envoy-postsubmit/master/fuzz_coverage/index.html). +The latest coverage report for main is available +[here](https://storage.googleapis.com/envoy-postsubmit/main/coverage/index.html). The latest fuzz coverage report for main is available [here](https://storage.googleapis.com/envoy-postsubmit/main/fuzz_coverage/index.html). It's also possible to specialize the coverage build to a specified test or test dir. This is useful when doing things like exploring the coverage of a fuzzer over its corpus. This can be done by diff --git a/ci/README.md b/ci/README.md index 54dbaef534fe5..aed383c05d2e7 100644 --- a/ci/README.md +++ b/ci/README.md @@ -6,24 +6,24 @@ and an image based on Windows2019. ## Ubuntu Envoy image The Ubuntu based Envoy Docker image at [`envoyproxy/envoy-build:`](https://hub.docker.com/r/envoyproxy/envoy-build/) is used for CircleCI checks, -where `` is specified in [`envoy_build_sha.sh`](https://github.com/envoyproxy/envoy/blob/master/ci/envoy_build_sha.sh). Developers -may work with the latest build image SHA in [envoy-build-tools](https://github.com/envoyproxy/envoy-build-tools/blob/master/toolchains/rbe_toolchains_config.bzl#L8) +where `` is specified in [`envoy_build_sha.sh`](https://github.com/envoyproxy/envoy/blob/main/ci/envoy_build_sha.sh). Developers +may work with the latest build image SHA in [envoy-build-tools](https://github.com/envoyproxy/envoy-build-tools/blob/main/toolchains/rbe_toolchains_config.bzl#L8) repo to provide a self-contained environment for building Envoy binaries and running tests that reflects the latest built Ubuntu Envoy image. Moreover, the Docker image at [`envoyproxy/envoy-dev:`](https://hub.docker.com/r/envoyproxy/envoy-dev/) is an image that has an Envoy binary at `/usr/local/bin/envoy`. -The `` corresponds to the master commit at which the binary was compiled. Lastly, `envoyproxy/envoy-dev:latest` contains an Envoy -binary built from the latest tip of master that passed tests. +The `` corresponds to the main commit at which the binary was compiled. Lastly, `envoyproxy/envoy-dev:latest` contains an Envoy +binary built from the latest tip of main that passed tests. ## Alpine Envoy image Minimal images based on Alpine Linux allow for quicker deployment of Envoy. Two Alpine based images are built, one with an Envoy binary with debug (`envoyproxy/envoy-alpine-debug`) symbols and one stripped of them (`envoyproxy/envoy-alpine`). Both images are pushed with two different tags: `` and `latest`. Parallel to the Ubuntu images above, `` corresponds to the -master commit at which the binary was compiled, and `latest` corresponds to a binary built from the latest tip of master that passed tests. +main commit at which the binary was compiled, and `latest` corresponds to a binary built from the latest tip of main that passed tests. ## Windows 2019 Envoy image The Windows 2019 based Envoy Docker image at [`envoyproxy/envoy-build-windows2019:`](https://hub.docker.com/r/envoyproxy/envoy-build-windows2019/) -is used for CI checks, where `` is specified in [`envoy_build_sha.sh`](https://github.com/envoyproxy/envoy/blob/master/ci/envoy_build_sha.sh). +is used for CI checks, where `` is specified in [`envoy_build_sha.sh`](https://github.com/envoyproxy/envoy/blob/main/ci/envoy_build_sha.sh). Developers may work with the most recent `envoyproxy/envoy-build-windows2019` image to provide a self-contained environment for building Envoy binaries and running tests that reflects the latest built Windows 2019 Envoy image. @@ -44,7 +44,7 @@ We use the Clang compiler for all Linux CI runs with tests. We have an additiona # C++ standard library As of November 2019 after [#8859](https://github.com/envoyproxy/envoy/pull/8859) the official released binary is -[linked against libc++ on Linux](https://github.com/envoyproxy/envoy/blob/master/bazel/README.md#linking-against-libc-on-linux). +[linked against libc++ on Linux](https://github.com/envoyproxy/envoy/blob/main/bazel/README.md#linking-against-libc-on-linux). To override the C++ standard library in your build, set environment variable `ENVOY_STDLIB` to `libstdc++` or `libc++` and run `./ci/do_ci.sh` as described below. @@ -98,7 +98,7 @@ For a debug version of the Envoy binary you can run: The build artifact can be found in `/tmp/envoy-docker-build/envoy/source/exe/envoy-debug` (or wherever `$ENVOY_DOCKER_BUILD_DIR` points). -To leverage a [bazel remote cache](https://github.com/envoyproxy/envoy/tree/master/bazel#advanced-caching-setup) add the http_remote_cache endpoint to +To leverage a [bazel remote cache](https://github.com/envoyproxy/envoy/tree/main/bazel#advanced-caching-setup) add the http_remote_cache endpoint to the BAZEL_BUILD_EXTRA_OPTIONS environment variable ```bash diff --git a/ci/api_mirror.sh b/ci/api_mirror.sh index 03e8ab85d80cb..8a3022b724318 100755 --- a/ci/api_mirror.sh +++ b/ci/api_mirror.sh @@ -3,8 +3,8 @@ set -e CHECKOUT_DIR=../data-plane-api -MAIN_BRANCH="refs/heads/master" -API_MAIN_BRANCH="master" +MAIN_BRANCH="refs/heads/main" +API_MAIN_BRANCH="main" if [[ "${AZP_BRANCH}" == "${MAIN_BRANCH}" ]]; then echo "Cloning..." diff --git a/ci/docker_ci.sh b/ci/docker_ci.sh index 1488ea726f988..f83e1f281a581 100755 --- a/ci/docker_ci.sh +++ b/ci/docker_ci.sh @@ -89,11 +89,11 @@ push_images() { docker push "${BUILD_TAG}" } -MASTER_BRANCH="refs/heads/master" +MAIN_BRANCH="refs/heads/main" RELEASE_BRANCH_REGEX="^refs/heads/release/v.*" RELEASE_TAG_REGEX="^refs/tags/v.*" -# For master builds and release branch builds use the dev repo. Otherwise we assume it's a tag and +# For main builds and release branch builds use the dev repo. Otherwise we assume it's a tag and # we push to the primary repo. if [[ "${AZP_BRANCH}" =~ ${RELEASE_TAG_REGEX} ]]; then IMAGE_POSTFIX="" @@ -126,11 +126,11 @@ ENVOY_DOCKER_TAR="${ENVOY_DOCKER_IMAGE_DIRECTORY}/envoy-docker-images.tar.xz" echo "Saving built images to ${ENVOY_DOCKER_TAR}." docker save "${IMAGES_TO_SAVE[@]}" | xz -T0 -2 >"${ENVOY_DOCKER_TAR}" -# Only push images for master builds, release branch builds, and tag builds. -if [[ "${AZP_BRANCH}" != "${MASTER_BRANCH}" ]] && +# Only push images for main builds, release branch builds, and tag builds. +if [[ "${AZP_BRANCH}" != "${MAIN_BRANCH}" ]] && ! [[ "${AZP_BRANCH}" =~ ${RELEASE_BRANCH_REGEX} ]] && ! [[ "${AZP_BRANCH}" =~ ${RELEASE_TAG_REGEX} ]]; then - echo 'Ignoring non-master branch or tag for docker push.' + echo 'Ignoring non-main branch or tag for docker push.' exit 0 fi @@ -139,8 +139,8 @@ docker login -u "$DOCKERHUB_USERNAME" -p "$DOCKERHUB_PASSWORD" for BUILD_TYPE in "${BUILD_TYPES[@]}"; do push_images "${BUILD_TYPE}" "${DOCKER_IMAGE_PREFIX}${BUILD_TYPE}${IMAGE_POSTFIX}:${IMAGE_NAME}" - # Only push latest on master builds. - if [[ "${AZP_BRANCH}" == "${MASTER_BRANCH}" ]]; then + # Only push latest on main builds. + if [[ "${AZP_BRANCH}" == "${MAIN_BRANCH}" ]]; then docker tag "${DOCKER_IMAGE_PREFIX}${BUILD_TYPE}${IMAGE_POSTFIX}:${IMAGE_NAME}" "${DOCKER_IMAGE_PREFIX}${BUILD_TYPE}${IMAGE_POSTFIX}:latest" push_images "${BUILD_TYPE}" "${DOCKER_IMAGE_PREFIX}${BUILD_TYPE}${IMAGE_POSTFIX}:latest" fi diff --git a/ci/filter_example_mirror.sh b/ci/filter_example_mirror.sh index 8602b1677e4b9..a511227714035 100755 --- a/ci/filter_example_mirror.sh +++ b/ci/filter_example_mirror.sh @@ -4,8 +4,8 @@ set -e ENVOY_SRCDIR=$(cd "$(dirname "${BASH_SOURCE[0]}")/../" && pwd) CHECKOUT_DIR=../envoy-filter-example -MAIN_BRANCH="refs/heads/master" -FILTER_EXAMPLE_MAIN_BRANCH="master" +MAIN_BRANCH="refs/heads/main" +FILTER_EXAMPLE_MAIN_BRANCH="main" if [[ "${AZP_BRANCH}" == "${MAIN_BRANCH}" ]]; then echo "Cloning..." diff --git a/ci/filter_example_setup.sh b/ci/filter_example_setup.sh index 0fd954bf2319a..fb25eb2100091 100644 --- a/ci/filter_example_setup.sh +++ b/ci/filter_example_setup.sh @@ -25,6 +25,7 @@ sed -e "s|{ENVOY_SRCDIR}|${ENVOY_SRCDIR}|" "${ENVOY_SRCDIR}"/ci/WORKSPACE.filter mkdir -p "${ENVOY_FILTER_EXAMPLE_SRCDIR}"/bazel ln -sf "${ENVOY_SRCDIR}"/bazel/get_workspace_status "${ENVOY_FILTER_EXAMPLE_SRCDIR}"/bazel/ cp -f "${ENVOY_SRCDIR}"/.bazelrc "${ENVOY_FILTER_EXAMPLE_SRCDIR}"/ +cp -f --remove-destination "${ENVOY_SRCDIR}"/.bazelversion "${ENVOY_FILTER_EXAMPLE_SRCDIR}"/ cp -f "$(bazel info workspace)"/*.bazelrc "${ENVOY_FILTER_EXAMPLE_SRCDIR}"/ export FILTER_WORKSPACE_SET=1 diff --git a/ci/go_mirror.sh b/ci/go_mirror.sh index 63f96d0d79697..96743eef62620 100755 --- a/ci/go_mirror.sh +++ b/ci/go_mirror.sh @@ -2,7 +2,7 @@ set -e -MAIN_BRANCH="refs/heads/master" +MAIN_BRANCH="refs/heads/main" # shellcheck source=ci/setup_cache.sh . "$(dirname "$0")"/setup_cache.sh diff --git a/configs/requirements.txt b/configs/requirements.txt index 07e1fe994fc33..1977ddd0bd3ad 100644 --- a/configs/requirements.txt +++ b/configs/requirements.txt @@ -34,4 +34,6 @@ MarkupSafe==1.1.1 \ --hash=sha256:cd5df75523866410809ca100dc9681e301e3c27567cf498077e8551b6d20e42f \ --hash=sha256:cdb132fc825c38e1aeec2c8aa9338310d29d337bebbd7baa06889d09a60a1fa2 \ --hash=sha256:e249096428b3ae81b08327a63a485ad0878de3fb939049038579ac0ef61e17e7 \ - --hash=sha256:e8313f01ba26fbbe36c7be1966a7b7424942f670f38e666995b88d012765b9be + --hash=sha256:e8313f01ba26fbbe36c7be1966a7b7424942f670f38e666995b88d012765b9be \ + --hash=sha256:d73a845f227b0bfe8a7455ee623525ee656a9e2e749e4742706d80a6065d5e2c + diff --git a/docs/README.md b/docs/README.md index 216e7bafcbade..d4ba08334fb94 100644 --- a/docs/README.md +++ b/docs/README.md @@ -6,7 +6,7 @@ In both cases, the generated output can be found in `generated/docs`. ## Building in an existing Envoy development environment -If you have an [existing Envoy development environment](https://github.com/envoyproxy/envoy/tree/master/bazel#quick-start-bazel-build-for-developers), you should have the necessary dependencies and requirements and be able to build the documentation directly. +If you have an [existing Envoy development environment](https://github.com/envoyproxy/envoy/tree/main/bazel#quick-start-bazel-build-for-developers), you should have the necessary dependencies and requirements and be able to build the documentation directly. ```bash ./docs/build.sh @@ -48,7 +48,7 @@ To do this: 1. The docs are published to [docs/envoy/latest](https://github.com/envoyproxy/envoyproxy.github.io/tree/master/docs/envoy/latest) on every commit to master. This process is handled by CircleCI with the - [`publish.sh`](https://github.com/envoyproxy/envoy/blob/master/docs/publish.sh) script. + [`publish.sh`](https://github.com/envoyproxy/envoy/blob/main/docs/publish.sh) script. 2. The docs are published to [docs/envoy](https://github.com/envoyproxy/envoyproxy.github.io/tree/master/docs/envoy) in a directory named after every tagged commit in this repo. Thus, on every tagged release there diff --git a/docs/publish.sh b/docs/publish.sh index c56e9bb31066f..9ff9684d7003a 100755 --- a/docs/publish.sh +++ b/docs/publish.sh @@ -13,7 +13,7 @@ DOCS_DIR=generated/docs CHECKOUT_DIR=envoy-docs BUILD_SHA=$(git rev-parse HEAD) -MAIN_BRANCH="refs/heads/master" +MAIN_BRANCH="refs/heads/main" RELEASE_TAG_REGEX="^refs/tags/v.*" if [[ "${AZP_BRANCH}" =~ ${RELEASE_TAG_REGEX} ]]; then @@ -25,7 +25,7 @@ else exit 0 fi -DOCS_MAIN_BRANCH="master" +DOCS_MAIN_BRANCH="main" echo 'cloning' git clone git@github.com:envoyproxy/envoyproxy.github.io "${CHECKOUT_DIR}" -b "${DOCS_MAIN_BRANCH}" --depth 1 diff --git a/docs/root/version_history/current.rst b/docs/root/version_history/current.rst index 586339d864dc5..8eb7e1aa33f16 100644 --- a/docs/root/version_history/current.rst +++ b/docs/root/version_history/current.rst @@ -77,6 +77,10 @@ Bug Fixes * aggregate cluster: fixed a crash due to a TLS initialization issue. * lua: fixed crash when Lua script contains streamInfo():downstreamSslConnection(). +* http: reverting a behavioral change where upstream connect timeouts were temporarily treated differently from other connection failures. The change back to the original behavior can be temporarily reverted by setting `envoy.reloadable_features.treat_upstream_connect_timeout_as_connect_failure` to false. + +* lua: fixed crash when Lua script contains streamInfo():downstreamSslConnection(). +* overload: fix a bug that can cause use-after-free when one scaled timer disables another one with the same duration. * tls: fix detection of the upstream connection close event. Removed Config or Runtime diff --git a/docs/root/version_history/v1.11.0.rst b/docs/root/version_history/v1.11.0.rst index 1bc4051b7da4a..10b48736b2db3 100644 --- a/docs/root/version_history/v1.11.0.rst +++ b/docs/root/version_history/v1.11.0.rst @@ -80,7 +80,7 @@ Changes * runtime: :ref:`Runtime Discovery Service (RTDS) ` support added to layered runtime configuration. * sandbox: added :ref:`CSRF sandbox `. * server: ``--define manual_stamp=manual_stamp`` was added to allow server stamping outside of binary rules. - more info in the `bazel docs `_. + more info in the `bazel docs `_. * server: added :ref:`server state ` statistic. * server: added :ref:`initialization_time_ms` statistic. * subset: added :ref:`list_as_any` option to diff --git a/docs/root/version_history/v1.14.0.rst b/docs/root/version_history/v1.14.0.rst index 2db9566c6788d..649a34d1cce34 100644 --- a/docs/root/version_history/v1.14.0.rst +++ b/docs/root/version_history/v1.14.0.rst @@ -187,6 +187,6 @@ Deprecated and the previous default can be enabled until the end of the deprecation period by enabling runtime feature `envoy.deprecated_features.grpc_stats_filter_enable_stats_for_all_methods_by_default`. * The :ref:`source_ip ` field in - `RBAC `_ has been deprecated + `RBAC `_ has been deprecated in favor of :ref:`direct_remote_ip ` and :ref:`remote_ip `. diff --git a/docs/root/version_history/v1.4.0.rst b/docs/root/version_history/v1.4.0.rst index f940deb1b5a65..fb81055386273 100644 --- a/docs/root/version_history/v1.4.0.rst +++ b/docs/root/version_history/v1.4.0.rst @@ -56,7 +56,7 @@ Deprecated * The following log macros have been deprecated: `log_trace`, `log_debug`, `conn_log`, `conn_log_info`, `conn_log_debug`, `conn_log_trace`, `stream_log`, `stream_log_info`, `stream_log_debug`, `stream_log_trace`. For replacements, please see - `logger.h `_. + `logger.h `_. * The connectionId() and ssl() callbacks of StreamFilterCallbacks have been deprecated and replaced with a more general connection() callback, which, when not returning a nullptr, can be used to get the connection id and SSL connection from the returned Connection object pointer. diff --git a/docs/root/version_history/v1.8.0.rst b/docs/root/version_history/v1.8.0.rst index 5f05f5d7d8eb1..e99c0e2c459c5 100644 --- a/docs/root/version_history/v1.8.0.rst +++ b/docs/root/version_history/v1.8.0.rst @@ -106,24 +106,24 @@ Deprecated * Use of the legacy `ratelimit.proto `_ is deprecated, in favor of the proto defined in - `date-plane-api `_ + `date-plane-api `_ Prior to 1.8.0, Envoy can use either proto to send client requests to a ratelimit server with the use of the - `use_data_plane_proto` boolean flag in the `ratelimit configuration `_. + `use_data_plane_proto` boolean flag in the `ratelimit configuration `_. However, when using the deprecated client a warning is logged. * Use of the --v2-config-only flag. * Use of both `use_websocket` and `websocket_config` in - `route.proto `_ + `route.proto `_ is deprecated. Please use the new `upgrade_configs` in the - `HttpConnectionManager `_ + `HttpConnectionManager `_ instead. -* Use of the integer `percent` field in `FaultDelay `_ - and in `FaultAbort `_ is deprecated in favor +* Use of the integer `percent` field in `FaultDelay `_ + and in `FaultAbort `_ is deprecated in favor of the new `FractionalPercent` based `percentage` field. * Setting hosts via `hosts` field in `Cluster` is deprecated. Use `load_assignment` instead. * Use of `response_headers_to_*` and `request_headers_to_add` are deprecated at the `RouteAction` level. Please use the configuration options at the `Route` level. * Use of `runtime` in `RouteMatch`, found in - `route.proto `_. + `route.proto `_. Set the `runtime_fraction` field instead. -* Use of the string `user` field in `Authenticated` in `rbac.proto `_ +* Use of the string `user` field in `Authenticated` in `rbac.proto `_ is deprecated in favor of the new `StringMatcher` based `principal_name` field. diff --git a/docs/root/version_history/v1.9.0.rst b/docs/root/version_history/v1.9.0.rst index 54cd1e4783360..12614ca1497b0 100644 --- a/docs/root/version_history/v1.9.0.rst +++ b/docs/root/version_history/v1.9.0.rst @@ -102,12 +102,12 @@ Changes Deprecated ---------- -* Order of execution of the network write filter chain has been reversed. Prior to this release cycle it was incorrect, see `#4599 `_. In the 1.9.0 release cycle we introduced `bugfix_reverse_write_filter_order` in `lds.proto `_ to temporarily support both old and new behaviors. Note this boolean field is deprecated. -* Order of execution of the HTTP encoder filter chain has been reversed. Prior to this release cycle it was incorrect, see `#4599 `_. In the 1.9.0 release cycle we introduced `bugfix_reverse_encode_order` in `http_connection_manager.proto `_ to temporarily support both old and new behaviors. Note this boolean field is deprecated. +* Order of execution of the network write filter chain has been reversed. Prior to this release cycle it was incorrect, see `#4599 `_. In the 1.9.0 release cycle we introduced `bugfix_reverse_write_filter_order` in `lds.proto `_ to temporarily support both old and new behaviors. Note this boolean field is deprecated. +* Order of execution of the HTTP encoder filter chain has been reversed. Prior to this release cycle it was incorrect, see `#4599 `_. In the 1.9.0 release cycle we introduced `bugfix_reverse_encode_order` in `http_connection_manager.proto `_ to temporarily support both old and new behaviors. Note this boolean field is deprecated. * Use of the v1 REST_LEGACY ApiConfigSource is deprecated. * Use of std::hash in the ring hash load balancer is deprecated. -* Use of `rate_limit_service` configuration in the `bootstrap configuration `_ is deprecated. +* Use of `rate_limit_service` configuration in the `bootstrap configuration `_ is deprecated. * Use of `runtime_key` in `RequestMirrorPolicy`, found in - `route.proto `_ + `route.proto `_ is deprecated. Set the `runtime_fraction` field instead. -* Use of buffer filter `max_request_time` is deprecated in favor of the request timeout found in `HttpConnectionManager `_ +* Use of buffer filter `max_request_time` is deprecated in favor of the request timeout found in `HttpConnectionManager `_ diff --git a/docs/root/version_history/version_history.rst b/docs/root/version_history/version_history.rst index 55bdaf928aeb7..57ca4d1b22c60 100644 --- a/docs/root/version_history/version_history.rst +++ b/docs/root/version_history/version_history.rst @@ -56,7 +56,7 @@ Deprecation Policy ^^^^^^^^^^^^^^^^^^ As of release 1.3.0, Envoy will follow a -`Breaking Change Policy `_. +`Breaking Change Policy `_. Features in the deprecated list for each version have been DEPRECATED and will be removed in the specified release cycle. A logged warning diff --git a/examples/grpc-bridge/docker-compose-protos.yaml b/examples/grpc-bridge/docker-compose-protos.yaml index 42da7d7407c73..543fe4bf5aca7 100644 --- a/examples/grpc-bridge/docker-compose-protos.yaml +++ b/examples/grpc-bridge/docker-compose-protos.yaml @@ -1,7 +1,7 @@ version: "3.7" # This is the conversion from a script to a dockerized version of the script -# https://github.com/envoyproxy/envoy/blob/master/examples/grpc-bridge/service/script/gen +# https://github.com/envoyproxy/envoy/blob/main/examples/grpc-bridge/service/script/gen services: # $ docker run -ti -v $(pwd):/protos -v $(pwd)/stubs:/stubs grpc/go protoc --go_out=plugins=grpc:/stubs -I/protos /protos/kv.proto diff --git a/generated_api_shadow/envoy/api/v2/core/protocol.proto b/generated_api_shadow/envoy/api/v2/core/protocol.proto index 9c47e388ee1af..ae1a86424cf07 100644 --- a/generated_api_shadow/envoy/api/v2/core/protocol.proto +++ b/generated_api_shadow/envoy/api/v2/core/protocol.proto @@ -201,7 +201,7 @@ message Http2ProtocolOptions { // Still under implementation. DO NOT USE. // // Allows metadata. See [metadata - // docs](https://github.com/envoyproxy/envoy/blob/master/source/docs/h2_metadata.md) for more + // docs](https://github.com/envoyproxy/envoy/blob/main/source/docs/h2_metadata.md) for more // information. bool allow_metadata = 6; diff --git a/generated_api_shadow/envoy/config/core/v3/protocol.proto b/generated_api_shadow/envoy/config/core/v3/protocol.proto index 17a6955d6851c..cb3179fd50aec 100644 --- a/generated_api_shadow/envoy/config/core/v3/protocol.proto +++ b/generated_api_shadow/envoy/config/core/v3/protocol.proto @@ -262,7 +262,7 @@ message Http2ProtocolOptions { // Still under implementation. DO NOT USE. // // Allows metadata. See [metadata - // docs](https://github.com/envoyproxy/envoy/blob/master/source/docs/h2_metadata.md) for more + // docs](https://github.com/envoyproxy/envoy/blob/main/source/docs/h2_metadata.md) for more // information. bool allow_metadata = 6; diff --git a/generated_api_shadow/envoy/config/core/v4alpha/protocol.proto b/generated_api_shadow/envoy/config/core/v4alpha/protocol.proto index 885972885ebc1..61d3fbe27e906 100644 --- a/generated_api_shadow/envoy/config/core/v4alpha/protocol.proto +++ b/generated_api_shadow/envoy/config/core/v4alpha/protocol.proto @@ -265,7 +265,7 @@ message Http2ProtocolOptions { // Still under implementation. DO NOT USE. // // Allows metadata. See [metadata - // docs](https://github.com/envoyproxy/envoy/blob/master/source/docs/h2_metadata.md) for more + // docs](https://github.com/envoyproxy/envoy/blob/main/source/docs/h2_metadata.md) for more // information. bool allow_metadata = 6; diff --git a/include/envoy/http/filter.h b/include/envoy/http/filter.h index 26e58c65858b7..7131a488e2230 100644 --- a/include/envoy/http/filter.h +++ b/include/envoy/http/filter.h @@ -47,7 +47,7 @@ enum class FilterHeadersStatus { // injectDecodedDataToFilterChain()/injectEncodedDataToFilterChain(), possibly multiple times // if the body needs to be divided into several chunks. The filter may need to handle // watermark events when injecting a body, see: - // https://github.com/envoyproxy/envoy/blob/master/source/docs/flow_control.md. + // https://github.com/envoyproxy/envoy/blob/main/source/docs/flow_control.md. // // The last call to inject data MUST have end_stream set to true to conclude the stream. // If the filter cannot provide a body the stream should be reset. diff --git a/security/email-templates.md b/security/email-templates.md index ec76e6d827487..3e6c178978661 100644 --- a/security/email-templates.md +++ b/security/email-templates.md @@ -36,14 +36,14 @@ Hello Envoy Distributors, The Envoy security team would like to provide advanced notice to the Envoy Private Distributors List of some details on the pending Envoy $VERSION security release, following the process described at -https://github.com/envoyproxy/envoy/blob/master/SECURITY.md. +https://github.com/envoyproxy/envoy/blob/main/SECURITY.md. This release will be made available on the $ORDINALDAY of $MONTH $YEAR at $PDTHOUR PDT ($GMTHOUR GMT). This release will fix $NUMDEFECTS security defect(s). The highest rated security defect is considered $SEVERITY severity. Below we provide details of these vulnerabilities under our embargo policy -(https://github.com/envoyproxy/envoy/blob/master/SECURITY.md#embargo-policy). +(https://github.com/envoyproxy/envoy/blob/main/SECURITY.md#embargo-policy). This information should be treated as confidential until public release by the Envoy maintainers on the Envoy GitHub. @@ -86,7 +86,7 @@ As a reminder, these patches are under embargo until $ORDINALDAY of $MONTH $YEAR at $PDTHOUR PDT ($GMTHOUR GMT). The information below should be treated as confidential and shared only on a need-to-know basis. The rules outline in our embargo policy -(https://github.com/envoyproxy/envoy/blob/master/SECURITY.md#embargo-policy) +(https://github.com/envoyproxy/envoy/blob/main/SECURITY.md#embargo-policy) still apply, and it is extremely important that any communication related to these CVEs are not forwarded further. diff --git a/security/postmortems/cve-2019-15225.md b/security/postmortems/cve-2019-15225.md index 1fbd027278229..7b3635ca70c15 100644 --- a/security/postmortems/cve-2019-15225.md +++ b/security/postmortems/cve-2019-15225.md @@ -130,7 +130,7 @@ amplify the effect of the O(n^2) process enough to produce a timeout. * The fixes for CVE-2019-15226 were straightforward and localized. * The security release occurred on time and followed the guidelines established in - https://github.com/envoyproxy/envoy/blob/master/SECURITY.md + https://github.com/envoyproxy/envoy/blob/main/SECURITY.md ### What went wrong diff --git a/security/postmortems/cve-2019-9900.md b/security/postmortems/cve-2019-9900.md index d6b6d38af5792..2766d1a647bae 100644 --- a/security/postmortems/cve-2019-9900.md +++ b/security/postmortems/cve-2019-9900.md @@ -303,7 +303,7 @@ All times US/Pacific number of users. 2019-04-04: -* 15:41 The Envoy master branch was frozen to prepare for the security release. PRs were rebased +* 15:41 The Envoy main branch was frozen to prepare for the security release. PRs were rebased against master and prepared for the release push. * 18:33 Envoy security team was contacted by a distributor who had noticed public visibility of binary images with the fix patch by other vendors. After discussion, we agreed on a general diff --git a/source/common/config/config_provider_impl.h b/source/common/config/config_provider_impl.h index 144332fe23b0f..21fa926b2116d 100644 --- a/source/common/config/config_provider_impl.h +++ b/source/common/config/config_provider_impl.h @@ -35,7 +35,7 @@ namespace Config { // and/or stream/request (if required by the configuration being processed). // // Dynamic configuration is distributed via xDS APIs (see -// https://github.com/envoyproxy/data-plane-api/blob/master/xds_protocol.rst). The framework exposed +// https://github.com/envoyproxy/data-plane-api/blob/main/xds_protocol.rst). The framework exposed // by these classes simplifies creation of client xDS implementations following a shared ownership // model, where according to the config source specification, a config subscription, config protos // received over the subscription and the subsequent config "implementation" (i.e., data structures diff --git a/source/common/event/scaled_range_timer_manager.cc b/source/common/event/scaled_range_timer_manager.cc index 10ac02b713cda..e90b0cc59c919 100644 --- a/source/common/event/scaled_range_timer_manager.cc +++ b/source/common/event/scaled_range_timer_manager.cc @@ -208,7 +208,11 @@ void ScaledRangeTimerManager::removeTimer(ScalingTimerHandle handle) { handle.queue_.range_timers_.erase(handle.iterator_); // Don't keep around empty queues if (handle.queue_.range_timers_.empty()) { - queues_.erase(handle.queue_); + // Skip erasing the queue if we're in the middle of processing timers for the queue. The + // queue will be erased in `onQueueTimerFired` after the queue entries have been processed. + if (!handle.queue_.processing_timers_) { + queues_.erase(handle.queue_); + } return; } @@ -238,12 +242,14 @@ void ScaledRangeTimerManager::onQueueTimerFired(Queue& queue) { // Pop and trigger timers until the one at the front isn't supposed to have expired yet (given the // current scale factor). + queue.processing_timers_ = true; while (!timers.empty() && computeTriggerTime(timers.front(), queue.duration_, scale_factor_) <= now) { auto item = std::move(queue.range_timers_.front()); queue.range_timers_.pop_front(); item.timer_.trigger(); } + queue.processing_timers_ = false; if (queue.range_timers_.empty()) { // Maintain the invariant that queues are never empty. diff --git a/source/common/event/scaled_range_timer_manager.h b/source/common/event/scaled_range_timer_manager.h index 1fbd51c8c86ee..db24c5a7d556d 100644 --- a/source/common/event/scaled_range_timer_manager.h +++ b/source/common/event/scaled_range_timer_manager.h @@ -81,6 +81,10 @@ class ScaledRangeTimerManager { // 2) on expiration // 3) when the scale factor changes const TimerPtr timer_; + + // A flag indicating whether the queue is currently processing timers. Used to guard against + // queue deletion during timer processing. + bool processing_timers_{false}; }; /** diff --git a/source/common/http/utility.cc b/source/common/http/utility.cc index 9dcf07691c00d..6aa003c6200ae 100644 --- a/source/common/http/utility.cc +++ b/source/common/http/utility.cc @@ -554,7 +554,7 @@ void Utility::sendLocalReply(const bool& is_reset, const EncodeFunctions& encode // TODO(dio): Probably it is worth to consider caching the encoded message based on gRPC // status. // JsonFormatter adds a '\n' at the end. For header value, it should be removed. - // https://github.com/envoyproxy/envoy/blob/master/source/common/formatter/substitution_formatter.cc#L129 + // https://github.com/envoyproxy/envoy/blob/main/source/common/formatter/substitution_formatter.cc#L129 if (body_text[body_text.length() - 1] == '\n') { body_text = body_text.substr(0, body_text.length() - 1); } diff --git a/source/common/router/upstream_request.cc b/source/common/router/upstream_request.cc index 5722deb78372c..4e0ffbd392752 100644 --- a/source/common/router/upstream_request.cc +++ b/source/common/router/upstream_request.cc @@ -340,7 +340,12 @@ void UpstreamRequest::onPoolFailure(ConnectionPool::PoolFailureReason reason, reset_reason = Http::StreamResetReason::ConnectionFailure; break; case ConnectionPool::PoolFailureReason::Timeout: - reset_reason = Http::StreamResetReason::LocalReset; + if (Runtime::runtimeFeatureEnabled( + "envoy.reloadable_features.treat_upstream_connect_timeout_as_connect_failure")) { + reset_reason = Http::StreamResetReason::ConnectionFailure; + } else { + reset_reason = Http::StreamResetReason::LocalReset; + } } // Mimic an upstream reset. diff --git a/source/common/runtime/runtime_features.cc b/source/common/runtime/runtime_features.cc index 56a7eb8189cbb..35c1b8585a111 100644 --- a/source/common/runtime/runtime_features.cc +++ b/source/common/runtime/runtime_features.cc @@ -89,6 +89,7 @@ constexpr const char* runtime_features[] = { "envoy.reloadable_features.stop_faking_paths", "envoy.reloadable_features.strict_1xx_and_204_response_headers", "envoy.reloadable_features.tls_use_io_handle_bio", + "envoy.reloadable_features.treat_upstream_connect_timeout_as_connect_failure", "envoy.reloadable_features.unify_grpc_handling", "envoy.restart_features.use_apple_api_for_dns_lookups", }; diff --git a/source/common/stats/thread_local_store.h b/source/common/stats/thread_local_store.h index 8ef60df207bac..9c9cd4bbefd69 100644 --- a/source/common/stats/thread_local_store.h +++ b/source/common/stats/thread_local_store.h @@ -141,7 +141,7 @@ using ParentHistogramImplSharedPtr = RefcountPtr; /** * Store implementation with thread local caching. For design details see - * https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md + * https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md */ class ThreadLocalStoreImpl : Logger::Loggable, public StoreRoot { public: diff --git a/source/common/stats/utility.h b/source/common/stats/utility.h index dab8ba396c19b..c00026ee16f2d 100644 --- a/source/common/stats/utility.h +++ b/source/common/stats/utility.h @@ -68,7 +68,7 @@ class Utility { * Creates a counter from a vector of tokens which are used to create the * name. The tokens can be specified as DynamicName or StatName. For * tokens specified as DynamicName, a dynamic StatName will be created. See - * https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md#dynamic-stat-tokens + * https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md#dynamic-stat-tokens * for more detail on why symbolic StatNames are preferred when possible. * * See also counterFromStatNames, which is slightly faster but does not allow @@ -101,7 +101,7 @@ class Utility { * Creates a gauge from a vector of tokens which are used to create the * name. The tokens can be specified as DynamicName or StatName. For * tokens specified as DynamicName, a dynamic StatName will be created. See - * https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md#dynamic-stat-tokens + * https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md#dynamic-stat-tokens * for more detail on why symbolic StatNames are preferred when possible. * * See also gaugeFromStatNames, which is slightly faster but does not allow @@ -138,7 +138,7 @@ class Utility { * Creates a histogram from a vector of tokens which are used to create the * name. The tokens can be specified as DynamicName or StatName. For * tokens specified as DynamicName, a dynamic StatName will be created. See - * https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md#dynamic-stat-tokens + * https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md#dynamic-stat-tokens * for more detail on why symbolic StatNames are preferred when possible. * * See also histogramFromStatNames, which is slightly faster but does not allow @@ -175,7 +175,7 @@ class Utility { * Creates a TextReadout from a vector of tokens which are used to create the * name. The tokens can be specified as DynamicName or StatName. For * tokens specified as DynamicName, a dynamic StatName will be created. See - * https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md#dynamic-stat-tokens + * https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md#dynamic-stat-tokens * for more detail on why symbolic StatNames are preferred when possible. * * See also TextReadoutFromStatNames, which is slightly faster but does not allow diff --git a/source/docs/network_filter_fuzzing.md b/source/docs/network_filter_fuzzing.md index 1777c77767745..8e40210cac24e 100644 --- a/source/docs/network_filter_fuzzing.md +++ b/source/docs/network_filter_fuzzing.md @@ -1,17 +1,17 @@ # Generic network-level filter fuzzers overview -Network filters need to be fuzzed. Filters come in two flavors, each with their own fuzzer. Read filters should be added into the [Generic ReadFilter Fuzzer](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/network_readfilter_fuzz_test.cc). Write Filters should added into the [Generic WriteFilter Fuzzer](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/network_writefilter_fuzz_test.cc). Some filters are both raed and write filters: They should be added into both fuzzers. +Network filters need to be fuzzed. Filters come in two flavors, each with their own fuzzer. Read filters should be added into the [Generic ReadFilter Fuzzer](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/network_readfilter_fuzz_test.cc). Write Filters should added into the [Generic WriteFilter Fuzzer](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/network_writefilter_fuzz_test.cc). Some filters are both raed and write filters: They should be added into both fuzzers. Before adding the new filter into the fuzzers, please make sure the filter is designed to accept untrusted inputs, or ready to be hardened to accept untrusted inputs. # Add a new ReadFilter into Generic Readfilter Fuzzer ## Step1. Make sure the filter can be linked into the fuzzer -There are two ways to link it into the fuzzer. -* [Recommended] In the file [extensions_build_config.bzl](https://github.com/envoyproxy/envoy/blob/master/source/extensions/extensions_build_config.bzl), the name of the filter should have a prefix `envoy.filters.network`. If it has such a prefix, the filter will be automatically linked into Generic ReadFilter Fuzzer. -* [Not recommended]If for some reasons the filter's name doesn't have such a prefix, the config of the filter must be added into the `deps` field of `network_readfilter_fuzz_test` module in the file [BUILD](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/BUILD). +There are two ways to link it into the fuzzer. +* [Recommended] In the file [extensions_build_config.bzl](https://github.com/envoyproxy/envoy/blob/main/source/extensions/extensions_build_config.bzl), the name of the filter should have a prefix `envoy.filters.network`. If it has such a prefix, the filter will be automatically linked into Generic ReadFilter Fuzzer. +* [Not recommended]If for some reasons the filter's name doesn't have such a prefix, the config of the filter must be added into the `deps` field of `network_readfilter_fuzz_test` module in the file [BUILD](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/BUILD). ### Step2. Add the filter name into supported_filter_names -In [uber_per_readfilter.cc](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/uber_per_readfilter.cc), add the filter name into the vector `supported_filter_names` in method `UberFilterFuzzer::filterNames()`. +In [uber_per_readfilter.cc](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/uber_per_readfilter.cc), add the filter name into the vector `supported_filter_names` in method `UberFilterFuzzer::filterNames()`. ``` const std::vector supported_filter_names = { ... @@ -22,7 +22,7 @@ NetworkFilterNames::get().ExtAuthorization, NetworkFilterNames::get().TheNewFilt # Add a new WriteFilter into Generic Writefilter Fuzzer ## Step 1. Make sure the filter can be linked into the fuzzer -For WriteFilter, the config of the filter must be added into the `deps` field of `network_writefilter_fuzz_test` module in the file [BUILD](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/BUILD). +For WriteFilter, the config of the filter must be added into the `deps` field of `network_writefilter_fuzz_test` module in the file [BUILD](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/BUILD). ``` envoy_cc_fuzz_test( name = "network_writefilter_fuzz_test", @@ -43,7 +43,7 @@ envoy_cc_fuzz_test( ) ``` ## Step 2. Add the filter name into supported_filter_names -In [uber_per_writefilter.cc](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/uber_per_writefilter.cc), add the filter name into the vector `supported_filter_names` in method `UberWriteFilterFuzzer::filterNames()`. +In [uber_per_writefilter.cc](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/uber_per_writefilter.cc), add the filter name into the vector `supported_filter_names` in method `UberWriteFilterFuzzer::filterNames()`. ``` const std::vector supported_filter_names = { ... @@ -54,8 +54,8 @@ const std::vector supported_filter_names = { # Add test cases into corpus Good test cases can provide good examples for fuzzers to find more paths in the code, increase the coverage and help find bugs more efficiently. -Each test case is a file under the folder [network_readfilter_corpus](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/network_readfilter_corpus) or [network_writefilter_corpus](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/network_writefilter_corpus). It consists of two parts: `config` and `actions`. -`config` is the protobuf to instantiate a filter, and `actions` are sequences of actions to take in order to test the filter. +Each test case is a file under the folder [network_readfilter_corpus](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/network_readfilter_corpus) or [network_writefilter_corpus](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/network_writefilter_corpus). It consists of two parts: `config` and `actions`. +`config` is the protobuf to instantiate a filter, and `actions` are sequences of actions to take in order to test the filter. An example for testing MongoProxy filter: ``` config { @@ -80,14 +80,14 @@ actions { } } ``` -* `config.name` is the name of the filter. -* `config.typed_config.type_url` is the type url of the filter config API. +* `config.name` is the name of the filter. +* `config.typed_config.type_url` is the type url of the filter config API. * `config.typed_config.value` is the serialized string of the config protobuf, and in C++ we can call`config.SerializeAsString()` to obtain this. This string may contain special characters. Recommend using octal or hexadecimal sequence for the string. * `actions.on_data.data` (or `actions.on_write.data`) is the buffer parameter `data`(in string format) for testing ReadFilter's method onData() (or for testing WriteFilter's method onWrite()). This string may contain special characters. Recommend using octal or hexadecimal sequence for the string. * `actions.on_data.end_stream` (or `actions.on_write.end_stream`) is the bool parameter `end_stream` for testing ReadFilter's method onData() (or for testing WriteFilter's method onWrite()). * `actions.on_new_connection` is an action to call `onNewConnection` method of a ReadFilter. * `actions.advance_time.milliseconds` is the duration in milliseconds for the simulatedSystemTime to advance by. -For more details, see the APIs for [ReadFilter Fuzz Testcase](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/network_readfilter_fuzz.proto) and [WriteFilter Fuzz Testcase](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/network_writefilter_fuzz.proto). +For more details, see the APIs for [ReadFilter Fuzz Testcase](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/network_readfilter_fuzz.proto) and [WriteFilter Fuzz Testcase](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/network_writefilter_fuzz.proto). ## Convert a unit test case to a fuzz test case manually This section explains an approach to generate a corpus from unit tests. It is an optional step for users who want to generate the highest possible coverage. @@ -105,12 +105,12 @@ static std::string toOct(const std::string& source, const std::string& info) { } ``` In the unit test code, we temporarily add a function(finally we will remove it) like the above one. -Then we can fill in `config.typed_config.value` with the value returned or printed by -```toOct(config.SerializeAsString(), "config serialized string: ")``` +Then we can fill in `config.typed_config.value` with the value returned or printed by +```toOct(config.SerializeAsString(), "config serialized string: ")``` where `config` is the config protobuf in a unit test case. -We can also fill in `actions.on_data.data` or `actions.on_write.data` with the value returned or printed by -```toOct(buffer.toString(), "buffer:")``` +We can also fill in `actions.on_data.data` or `actions.on_write.data` with the value returned or printed by +```toOct(buffer.toString(), "buffer:")``` where `buffer` is the buffer to pass to `onData()` or `onWrite()` in a unit test case. Please note that the two fuzzers use the "real input" for fuzzers. If you are using a mock decoder and pass an empty buffer to onData(), that test case won't help cover much code in the fuzzers(but the config protobuf is still helpful). diff --git a/source/docs/repokitteh.md b/source/docs/repokitteh.md index 1d2b747bdacba..5997332b600f4 100644 --- a/source/docs/repokitteh.md +++ b/source/docs/repokitteh.md @@ -8,7 +8,7 @@ The application is installed on specific GitHub repositories and interacts with these by receiving webhooks and making GitHub API calls. A root `repokitteh.star` script tells the application what to do based on the webhook received. ## Integration with Envoy -The file [repokitteh.star](https://github.com/envoyproxy/envoy/blob/master/repokitteh.star), which resides in the root of the Envoy repository tells RepoKitteh what functionality to use. The file is written in the [Starlark language](https://github.com/bazelbuild/starlark/), which is a Python dialect with well defined threading and hermeticity guarantees. +The file [repokitteh.star](https://github.com/envoyproxy/envoy/blob/main/repokitteh.star), which resides in the root of the Envoy repository tells RepoKitteh what functionality to use. The file is written in the [Starlark language](https://github.com/bazelbuild/starlark/), which is a Python dialect with well defined threading and hermeticity guarantees. For example, the statement ``` @@ -75,7 +75,7 @@ Sets the label `waiting:any` on a PR. When a new commit is pushed or any comment [Demo PR](https://github.com/envoyproxy/envoybot/pull/15) -### [CircleCI Retest](https://github.com/repokitteh/modules/blob/master/circleci.star) +### [CircleCI Retest](https://github.com/repokitteh/modules/blob/main/circleci.star) Restart failed CircleCI tests. Example: @@ -86,7 +86,7 @@ Restarts all failed CircleCI tests, as reported in the commit statuses. [Demo PR](https://github.com/envoyproxy/envoy/pull/12613#issuecomment-676141200) -### [Azure Pipelines Retest](https://github.com/envoyproxy/envoy/blob/master/ci/repokitteh/modules/azure_pipelines.star) +### [Azure Pipelines Retest](https://github.com/envoyproxy/envoy/blob/main/ci/repokitteh/modules/azure_pipelines.star) Restart failed Azure pipelines. Example: diff --git a/source/docs/stats.md b/source/docs/stats.md index 418a04f628d74..20c702ca7c106 100644 --- a/source/docs/stats.md +++ b/source/docs/stats.md @@ -25,7 +25,7 @@ https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310 for details. This requires lock-free access to stats on the fast path -- when proxying requests. For stats, this is implemented in -[ThreadLocalStore](https://github.com/envoyproxy/envoy/blob/master/source/common/stats/thread_local_store.h), supporting the following features: +[ThreadLocalStore](https://github.com/envoyproxy/envoy/blob/main/source/common/stats/thread_local_store.h), supporting the following features: * Thread local per scope stat caching. * Overlapping scopes with proper reference counting (2 scopes with the same name will point to @@ -94,12 +94,12 @@ maintain data continuity as scopes are re-created during operation. Stat names are replicated in several places in various forms. * Held with the stat values, in `CounterImpl`, `GaugeImpl` and `TextReadoutImpl`, which are defined in - [allocator_impl.cc](https://github.com/envoyproxy/envoy/blob/master/source/common/stats/allocator_impl.cc) - * In [MetricImpl](https://github.com/envoyproxy/envoy/blob/master/source/common/stats/metric_impl.h) + [allocator_impl.cc](https://github.com/envoyproxy/envoy/blob/main/source/common/stats/allocator_impl.cc) + * In [MetricImpl](https://github.com/envoyproxy/envoy/blob/main/source/common/stats/metric_impl.h) in a transformed state, with tags extracted into vectors of name/value strings. * In static strings across the codebase where stats are referenced * In a [set of - regexes](https://github.com/envoyproxy/envoy/blob/master/source/common/config/well_known_names.cc) + regexes](https://github.com/envoyproxy/envoy/blob/main/source/common/config/well_known_names.cc) used to perform tag extraction. There are stat maps in `ThreadLocalStore` for capturing all stats in a scope, @@ -127,7 +127,7 @@ The transformation between flattened string and symbolized form is CPU-intensive at scale. It requires parsing, encoding, and lookups in a shared map, which must be mutex-protected. To avoid adding latency and CPU overhead while serving requests, the tokens can be symbolized and saved in context classes, such as -[Http::CodeStatsImpl](https://github.com/envoyproxy/envoy/blob/master/source/common/http/codes.h). +[Http::CodeStatsImpl](https://github.com/envoyproxy/envoy/blob/main/source/common/http/codes.h). Symbolization can occur on startup or when new hosts or clusters are configured dynamically. Users of stats that are allocated dynamically per cluster, host, etc, must explicitly store partial stat-names their class instances, which later @@ -184,7 +184,7 @@ showing the memory layout for a few scenarios of constructing and joining symbol There are several ways to create hot-path contention looking up stats by name, and there is no bulletproof way to prevent it from occurring. - * The [stats macros](https://github.com/envoyproxy/envoy/blob/master/include/envoy/stats/stats_macros.h) may be used in a data structure which is constructed in response to requests. + * The [stats macros](https://github.com/envoyproxy/envoy/blob/main/include/envoy/stats/stats_macros.h) may be used in a data structure which is constructed in response to requests. * An explicit symbol-table lookup, via `StatNamePool` or `StatNameSet` can be made in the hot path. @@ -208,7 +208,7 @@ SymbolTableImpl::Encoding | | Helper class for incrementally encoding strings in StatName | | Provides an API and a view into a StatName (dynamic orsymbolized). Like absl::string_view, the backing store must be separately maintained. StatNameStorageBase | | Holds storage (an array of bytes) for a dynamic or symbolized StatName StatNameStorage | StatNameStorageBase | Holds storage for a symbolized StatName. Must be explicitly freed (not just destructed). -StatNameManagedStorage | StatNameStorage | Like StatNameStorage, but is 8 bytes larger, and can be destructed without free(). +StatNameManagedStorage | StatNameStorage | Like StatNameStorage, but is 8 bytes larger, and can be destructed without free(). StatNameDynamicStorage | StatNameStorageBase | Holds StatName storage for a dynamic (not symbolized) StatName. StatNamePool | | Holds backing store for any number of symbolized StatNames. StatNameDynamicPool | | Holds backing store for any number of dynamic StatNames. @@ -249,7 +249,7 @@ deployments with O(10k) clusters or hosts. To improve visibility for this memory growth, there are [memory-usage integration -tests](https://github.com/envoyproxy/envoy/blob/master/test/integration/stats_integration_test.cc). +tests](https://github.com/envoyproxy/envoy/blob/main/test/integration/stats_integration_test.cc). If a PR fails the tests in that file due to unexpected memory consumption, it gives the author and reviewer an opportunity to consider the cost/value of the @@ -266,4 +266,3 @@ Developers trying to can iterate through changes in these tests locally with: bazel test -c opt --test_env=ENVOY_MEMORY_TEST_EXACT=true \ test/integration:stats_integration_test ``` - diff --git a/source/extensions/filters/network/kafka/requirements.txt b/source/extensions/filters/network/kafka/requirements.txt index 07e1fe994fc33..1977ddd0bd3ad 100644 --- a/source/extensions/filters/network/kafka/requirements.txt +++ b/source/extensions/filters/network/kafka/requirements.txt @@ -34,4 +34,6 @@ MarkupSafe==1.1.1 \ --hash=sha256:cd5df75523866410809ca100dc9681e301e3c27567cf498077e8551b6d20e42f \ --hash=sha256:cdb132fc825c38e1aeec2c8aa9338310d29d337bebbd7baa06889d09a60a1fa2 \ --hash=sha256:e249096428b3ae81b08327a63a485ad0878de3fb939049038579ac0ef61e17e7 \ - --hash=sha256:e8313f01ba26fbbe36c7be1966a7b7424942f670f38e666995b88d012765b9be + --hash=sha256:e8313f01ba26fbbe36c7be1966a7b7424942f670f38e666995b88d012765b9be \ + --hash=sha256:d73a845f227b0bfe8a7455ee623525ee656a9e2e749e4742706d80a6065d5e2c + diff --git a/test/README.md b/test/README.md index 2746efe98c8db..85f12625902f1 100644 --- a/test/README.md +++ b/test/README.md @@ -10,7 +10,7 @@ various classes, macros, and matchers that Envoy uses from those frameworks. Envoy contains an integration testing framework, for testing downstream-Envoy-upstream communication. -[See the framework's README for more information.](https://github.com/envoyproxy/envoy/blob/master/test/integration/README.md) +[See the framework's README for more information.](https://github.com/envoyproxy/envoy/blob/main/test/integration/README.md) ## Custom matchers @@ -93,7 +93,7 @@ EXPECT_THAT(response->headers(), IsSupersetOfHeaders(required_headers)); ## Controlling time in tests In Envoy production code, time and timers are managed via -[`Event::TimeSystem`](https://github.com/envoyproxy/envoy/blob/master/include/envoy/event/timer.h), +[`Event::TimeSystem`](https://github.com/envoyproxy/envoy/blob/main/include/envoy/event/timer.h), which provides a mechanism for querying the time and setting up time-based callbacks. Bypassing this abstraction in Envoy code is flagged as a format violation in CI. @@ -127,7 +127,7 @@ Envoy uses [Google Benchmark](https://github.com/google/benchmark/) for microbenchmarks. There are custom bazel rules, `envoy_cc_benchmark_binary` and `envoy_benchmark_test`, to execute them locally and in CI environments respectively. `envoy_benchmark_test` rules call the benchmark binary from a -[script](https://github.com/envoyproxy/envoy/blob/master/bazel/test_for_benchmark_wrapper.sh) +[script](https://github.com/envoyproxy/envoy/blob/main/bazel/test_for_benchmark_wrapper.sh) which runs the benchmark with a minimal number of iterations and skipping expensive benchmarks to quickly verify that the binary is able to run to completion. In order to collect meaningful bechmarks, `bazel run -c opt` the @@ -135,4 +135,4 @@ benchmark binary target on a quiescent machine. If you would like to detect when your benchmark test is running under the wrapper, call -[`Envoy::benchmark::skipExpensiveBechmarks()`](https://github.com/envoyproxy/envoy/blob/master/test/benchmark/main.h). +[`Envoy::benchmark::skipExpensiveBechmarks()`](https://github.com/envoyproxy/envoy/blob/main/test/benchmark/main.h). diff --git a/test/common/event/scaled_range_timer_manager_test.cc b/test/common/event/scaled_range_timer_manager_test.cc index ff9bcab087726..f0a6d2edab3f2 100644 --- a/test/common/event/scaled_range_timer_manager_test.cc +++ b/test/common/event/scaled_range_timer_manager_test.cc @@ -147,6 +147,56 @@ TEST_F(ScaledRangeTimerManagerTest, DisableWhileScalingMax) { simTime().advanceTimeAndRun(std::chrono::seconds(100), dispatcher_, Dispatcher::RunType::Block); } +TEST_F(ScaledRangeTimerManagerTest, InCallbackDisableLastTimerInSameQueue) { + ScaledRangeTimerManager manager(dispatcher_); + + MockFunction callback1; + auto timer1 = manager.createTimer(callback1.AsStdFunction()); + MockFunction callback2; + auto timer2 = manager.createTimer(callback2.AsStdFunction()); + + timer1->enableTimer(std::chrono::seconds(0), std::chrono::seconds(95)); + timer2->enableTimer(std::chrono::seconds(5), std::chrono::seconds(100)); + + simTime().advanceTimeAndRun(std::chrono::seconds(5), dispatcher_, Dispatcher::RunType::Block); + + EXPECT_TRUE(timer1->enabled()); + EXPECT_TRUE(timer2->enabled()); + + EXPECT_CALL(callback1, Call).WillOnce(Invoke([&]() { + timer2->disableTimer(); + timer2.reset(); + })); + + // Run the dispatcher to make sure nothing happens when it's not supposed to. + simTime().advanceTimeAndRun(std::chrono::seconds(100), dispatcher_, Dispatcher::RunType::Block); +} + +TEST_F(ScaledRangeTimerManagerTest, InCallbackDisableTimerInOtherQueue) { + ScaledRangeTimerManager manager(dispatcher_); + + MockFunction callback1; + auto timer1 = manager.createTimer(callback1.AsStdFunction()); + MockFunction callback2; + auto timer2 = manager.createTimer(callback2.AsStdFunction()); + + timer1->enableTimer(std::chrono::seconds(5), std::chrono::seconds(95)); + timer2->enableTimer(std::chrono::seconds(5), std::chrono::seconds(100)); + + simTime().advanceTimeAndRun(std::chrono::seconds(5), dispatcher_, Dispatcher::RunType::Block); + + EXPECT_TRUE(timer1->enabled()); + EXPECT_TRUE(timer2->enabled()); + + EXPECT_CALL(callback1, Call).WillOnce(Invoke([&]() { + timer2->disableTimer(); + timer2.reset(); + })); + + // Run the dispatcher to make sure nothing happens when it's not supposed to. + simTime().advanceTimeAndRun(std::chrono::seconds(100), dispatcher_, Dispatcher::RunType::Block); +} + TEST_F(ScaledRangeTimerManagerTest, DisableWithZeroMinTime) { ScaledRangeTimerManager manager(dispatcher_); diff --git a/test/common/router/router_test.cc b/test/common/router/router_test.cc index f739a2c857eee..54365731d78f8 100644 --- a/test/common/router/router_test.cc +++ b/test/common/router/router_test.cc @@ -510,6 +510,76 @@ TEST_F(RouterTest, PoolFailureWithPriority) { "upstream_reset_before_response_started{connection failure,tls version mismatch}"); } +TEST_F(RouterTest, PoolFailureDueToConnectTimeout) { + ON_CALL(callbacks_.route_->route_entry_, priority()) + .WillByDefault(Return(Upstream::ResourcePriority::High)); + EXPECT_CALL(cm_, httpConnPoolForCluster(_, Upstream::ResourcePriority::High, _, &router_)); + EXPECT_CALL(cm_.conn_pool_, newStream(_, _)) + .WillOnce(Invoke([&](Http::StreamDecoder&, Http::ConnectionPool::Callbacks& callbacks) + -> Http::ConnectionPool::Cancellable* { + callbacks.onPoolFailure(ConnectionPool::PoolFailureReason::Timeout, "connect_timeout", + cm_.conn_pool_.host_); + return nullptr; + })); + + Http::TestResponseHeaderMapImpl response_headers{ + {":status", "503"}, {"content-length", "134"}, {"content-type", "text/plain"}}; + EXPECT_CALL(callbacks_, encodeHeaders_(HeaderMapEqualRef(&response_headers), false)); + EXPECT_CALL(callbacks_, encodeData(_, true)); + EXPECT_CALL(callbacks_.stream_info_, + setResponseFlag(StreamInfo::ResponseFlag::UpstreamConnectionFailure)); + EXPECT_CALL(callbacks_.stream_info_, onUpstreamHostSelected(_)) + .WillOnce(Invoke([&](const Upstream::HostDescriptionConstSharedPtr host) -> void { + EXPECT_EQ(host_address_, host->address()); + })); + + Http::TestRequestHeaderMapImpl headers; + HttpTestUtility::addDefaultHeaders(headers); + router_.decodeHeaders(headers, true); + EXPECT_TRUE(verifyHostUpstreamStats(0, 1)); + // Pool failure, so upstream request was not initiated. + EXPECT_EQ(0U, + callbacks_.route_->route_entry_.virtual_cluster_.stats().upstream_rq_total_.value()); + EXPECT_EQ(callbacks_.details(), + "upstream_reset_before_response_started{connection failure,connect_timeout}"); +} + +TEST_F(RouterTest, PoolFailureDueToConnectTimeoutLegacy) { + TestScopedRuntime scoped_runtime; + Runtime::LoaderSingleton::getExisting()->mergeValues( + {{"envoy.reloadable_features.treat_upstream_connect_timeout_as_connect_failure", "false"}}); + ON_CALL(callbacks_.route_->route_entry_, priority()) + .WillByDefault(Return(Upstream::ResourcePriority::High)); + EXPECT_CALL(cm_, httpConnPoolForCluster(_, Upstream::ResourcePriority::High, _, &router_)); + EXPECT_CALL(cm_.conn_pool_, newStream(_, _)) + .WillOnce(Invoke([&](Http::StreamDecoder&, Http::ConnectionPool::Callbacks& callbacks) + -> Http::ConnectionPool::Cancellable* { + callbacks.onPoolFailure(ConnectionPool::PoolFailureReason::Timeout, "connect_timeout", + cm_.conn_pool_.host_); + return nullptr; + })); + + Http::TestResponseHeaderMapImpl response_headers{ + {":status", "503"}, {"content-length", "127"}, {"content-type", "text/plain"}}; + EXPECT_CALL(callbacks_, encodeHeaders_(HeaderMapEqualRef(&response_headers), false)); + EXPECT_CALL(callbacks_, encodeData(_, true)); + EXPECT_CALL(callbacks_.stream_info_, setResponseFlag(StreamInfo::ResponseFlag::LocalReset)); + EXPECT_CALL(callbacks_.stream_info_, onUpstreamHostSelected(_)) + .WillOnce(Invoke([&](const Upstream::HostDescriptionConstSharedPtr host) -> void { + EXPECT_EQ(host_address_, host->address()); + })); + + Http::TestRequestHeaderMapImpl headers; + HttpTestUtility::addDefaultHeaders(headers); + router_.decodeHeaders(headers, true); + EXPECT_TRUE(verifyHostUpstreamStats(0, 1)); + // Pool failure, so upstream request was not initiated. + EXPECT_EQ(0U, + callbacks_.route_->route_entry_.virtual_cluster_.stats().upstream_rq_total_.value()); + EXPECT_EQ(callbacks_.details(), + "upstream_reset_before_response_started{local reset,connect_timeout}"); +} + TEST_F(RouterTest, Http1Upstream) { EXPECT_CALL(cm_, httpConnPoolForCluster(_, _, absl::optional(), _)); EXPECT_CALL(cm_.conn_pool_, newStream(_, _)).WillOnce(Return(&cancellable_)); diff --git a/test/common/upstream/health_check_fuzz.cc b/test/common/upstream/health_check_fuzz.cc index fa21636cb3356..bc22066325443 100644 --- a/test/common/upstream/health_check_fuzz.cc +++ b/test/common/upstream/health_check_fuzz.cc @@ -296,7 +296,7 @@ void TcpHealthCheckFuzz::raiseEvent(const Network::ConnectionEvent& event_type, } // In the specific case of: - // https://github.com/envoyproxy/envoy/blob/master/source/common/upstream/health_checker_impl.cc#L489 + // https://github.com/envoyproxy/envoy/blob/main/source/common/upstream/health_checker_impl.cc#L489 // This blows away client, should create a new one if (event_type == Network::ConnectionEvent::Connected && empty_response_) { ENVOY_LOG_MISC(trace, "Will create client from connected event and empty response."); diff --git a/test/extensions/filters/network/common/fuzz/README.md b/test/extensions/filters/network/common/fuzz/README.md index 21181c8402a4f..d35fb5d92dbcf 100644 --- a/test/extensions/filters/network/common/fuzz/README.md +++ b/test/extensions/filters/network/common/fuzz/README.md @@ -1,2 +1,2 @@ -Network filters need to be fuzzed. Filters come in two flavors, each with their own fuzzer. Read filters should be added into the [Generic ReadFilter Fuzzer](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/network_readfilter_fuzz_test.cc). Write Filters should added into the [Generic WriteFilter Fuzzer](https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/common/fuzz/network_writefilter_fuzz_test.cc). Some filters are both raed and write filters: They should be added into both fuzzers. -To add a new filter into generic network level filter fuzzers, see the [doc](https://github.com/envoyproxy/envoy/blob/master/source/docs/network_filter_fuzzing.md). \ No newline at end of file +Network filters need to be fuzzed. Filters come in two flavors, each with their own fuzzer. Read filters should be added into the [Generic ReadFilter Fuzzer](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/network_readfilter_fuzz_test.cc). Write Filters should added into the [Generic WriteFilter Fuzzer](https://github.com/envoyproxy/envoy/blob/main/test/extensions/filters/network/common/fuzz/network_writefilter_fuzz_test.cc). Some filters are both raed and write filters: They should be added into both fuzzers. +To add a new filter into generic network level filter fuzzers, see the [doc](https://github.com/envoyproxy/envoy/blob/main/source/docs/network_filter_fuzzing.md). \ No newline at end of file diff --git a/test/integration/stats_integration_test.cc b/test/integration/stats_integration_test.cc index c264096681f38..1683a3db13dc6 100644 --- a/test/integration/stats_integration_test.cc +++ b/test/integration/stats_integration_test.cc @@ -279,7 +279,7 @@ TEST_P(ClusterMemoryTestRunner, MemoryLargeClusterSize) { // vary. // // If you encounter a failure here, please see - // https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md#stats-memory-tests + // https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md#stats-memory-tests // for details on how to fix. // // We only run the exact test for ipv6 because ipv4 in some cases may allocate a @@ -325,7 +325,7 @@ TEST_P(ClusterMemoryTestRunner, MemoryLargeHostSizeWithStats) { // at the logs. // // If you encounter a failure here, please see - // https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md#stats-memory-tests + // https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md#stats-memory-tests // for details on how to fix. // // We only run the exact test for ipv6 because ipv4 in some cases may allocate a diff --git a/tools/api/generate_go_protobuf.py b/tools/api/generate_go_protobuf.py index 5b25de2dbb0a4..23ef195c84cd9 100755 --- a/tools/api/generate_go_protobuf.py +++ b/tools/api/generate_go_protobuf.py @@ -16,7 +16,7 @@ IMPORT_BASE = 'github.com/envoyproxy/go-control-plane' OUTPUT_BASE = 'build_go' REPO_BASE = 'go-control-plane' -BRANCH = 'master' +BRANCH = 'main' MIRROR_MSG = 'Mirrored from envoyproxy/envoy @ ' USER_NAME = 'go-control-plane(Azure Pipelines)' USER_EMAIL = 'go-control-plane@users.noreply.github.com' diff --git a/tools/git/last_github_commit.sh b/tools/git/last_github_commit.sh index 9746d259ac3ba..2ca2fb0fda29e 100755 --- a/tools/git/last_github_commit.sh +++ b/tools/git/last_github_commit.sh @@ -1,8 +1,8 @@ #!/bin/bash -# Looking back from HEAD, find the first commit that was merged onto master by GitHub. This is +# Looking back from HEAD, find the first commit that was merged onto main by GitHub. This is # likely the last non-local change on a given branch. There may be some exceptions for this -# heuristic, e.g. when patches are manually merged for security fixes on master, but this is very +# heuristic, e.g. when patches are manually merged for security fixes on main, but this is very # rare. git rev-list --no-merges --committer="GitHub " --max-count=1 HEAD diff --git a/tools/proto_format/proto_sync.py b/tools/proto_format/proto_sync.py index 47d95871833d2..ccba28eb718d3 100755 --- a/tools/proto_format/proto_sync.py +++ b/tools/proto_format/proto_sync.py @@ -433,7 +433,7 @@ def Sync(api_root, mode, labels, shadow): if deleted_files: print('The following files will be deleted: %s' % sorted(deleted_files)) print( - 'If this is not intended, please see https://github.com/envoyproxy/envoy/blob/master/api/STYLE.md#adding-an-extension-configuration-to-the-api.' + 'If this is not intended, please see https://github.com/envoyproxy/envoy/blob/main/api/STYLE.md#adding-an-extension-configuration-to-the-api.' ) if input('Delete files? [yN] ').strip().lower() == 'y': subprocess.run(['patch', '-p1'], input=diff, cwd=str(api_root_path.resolve()))