[1.17] backport recent changes to main

.github/workflows/pr-unit-tests.yaml

@@ -0,0 +1,46 @@
+name: Unit Tests
+
+# This workflow invokes unit tests for the Gloo Gateway project
+# It was introduced during the 1.17 quarter, where we added a new project (projects/gateway2)
+# and therefore we only run those new tests here
+#
+# Our historical unit tests are run via CloudBuild
+# Overtime, it would be valuable to consolidate these approaches
+
+on:
+  pull_request:
+    types: [opened, synchronize, reopened, ready_for_review]
+
+jobs:
+  # Runs the unit tests for `projects/gateway2`
+  kube_gateway_project:
+    name: projects/gateway2
+    runs-on: ubuntu-22.04
+    timeout-minutes: 10
+    # Other unit tests are run by our CloudBuild runner
+    # These tests do run on Draft PRs, and so we maintain that consistency and run this job on Draft PRs as well
+    steps:
+    - uses: actions/checkout@v4
+    - name: Setup Go
+      uses: actions/setup-go@v5
+      with:
+        go-version-file: go.mod
+    - name: Build
+      run: go build -v ./projects/gateway2/... ./projects/gloo/cli/cmd
+    - name: Install Test Utils
+      shell: bash
+      run: make -C ./projects/gateway2/ install-go-tools
+    - name: Install Test Coverage Tools
+      shell: bash
+      run: make install-go-test-coverage
+    - name: Run Tests
+      shell: bash
+      env:
+        TEST_PKG: ./projects/gateway2/...
+      run: make go-test-with-coverage
+    - name: Validate Test Coverage
+      shell: bash
+      # The make will error if test coverage drops below a certain threshold
+      # We intentionally ignore the errors while we build out our test coverage, to establish a good baseline
+      # However, we should strive to establish a baseline, and then make it required on PRs
+      run: make --always-make --ignore-errors validate-test-coverage

Makefile

@@ -165,6 +165,10 @@ install-go-tools: mod-download ## Download and install Go dependencies
 	go install github.com/golangci/golangci-lint/cmd/golangci-lint@$(LINTER_VERSION)
 	go install github.com/quasilyte/go-ruleguard/cmd/ruleguard@v0.3.16
 
+.PHONY: install-go-test-coverage
+install-go-test-coverage:
+	go install github.com/vladopajic/go-test-coverage/v2@v2.8.1
+
 .PHONY: check-format
 check-format:
 	NOT_FORMATTED=$$(gofmt -l ./projects/ ./pkg/ ./test/) && if [ -n "$$NOT_FORMATTED" ]; then echo These files are not formatted: $$NOT_FORMATTED; exit 1; fi
@@ -194,7 +198,7 @@ GINKGO_VERSION ?= $(shell echo $(shell go list -m github.com/onsi/ginkgo/v2) | c
 GINKGO_ENV ?= GOLANG_PROTOBUF_REGISTRATION_CONFLICT=ignore ACK_GINKGO_RC=true ACK_GINKGO_DEPRECATIONS=$(GINKGO_VERSION)
 GINKGO_FLAGS ?= -tags=purego --trace -progress -race --fail-fast -fail-on-pending --randomize-all --compilers=5
 GINKGO_REPORT_FLAGS ?= --json-report=test-report.json --junit-report=junit.xml -output-dir=$(OUTPUT_DIR)
-GINKGO_COVERAGE_FLAGS ?= --cover --covermode=count --coverprofile=coverage.cov
+GINKGO_COVERAGE_FLAGS ?= --cover --covermode=atomic --coverprofile=coverage.cov
 TEST_PKG ?= ./... # Default to run all tests
 
 # This is a way for a user executing `make test` to be able to provide flags which we do not include by default
@@ -237,6 +241,7 @@ test: ## Run all tests, or only run the test package at {TEST_PKG} if it is spec
 	$(GINKGO_FLAGS) $(GINKGO_REPORT_FLAGS) $(GINKGO_USER_FLAGS) \
 	$(TEST_PKG)
 
+# https://go.dev/blog/cover#heat-maps
 .PHONY: test-with-coverage
 test-with-coverage: GINKGO_FLAGS += $(GINKGO_COVERAGE_FLAGS)
 test-with-coverage: test
@@ -277,7 +282,8 @@ GO_TEST_ENV ?= GOLANG_PROTOBUF_REGISTRATION_CONFLICT=ignore
 # Testings flags: https://pkg.go.dev/cmd/go#hdr-Testing_flags
 # The default timeout for a suite is 10 minutes, but this can be overridden by setting the -timeout flag. Currently set
 # to 25 minutes based on the time it takes to run the longest test setup (k8s_gw_test).
-GO_TEST_ARGS ?= -timeout=25m -cpu=4 -race
+GO_TEST_ARGS ?= -timeout=25m -cpu=4 -race -outputdir=$(OUTPUT_DIR)
+GO_TEST_COVERAGE_ARGS ?= --cover --covermode=atomic --coverprofile=cover.out
 
 # This is a way for a user executing `make go-test` to be able to provide args which we do not include by default
 # For example, you may want to run tests multiple times, or with various timeouts
@@ -290,6 +296,19 @@ go-test: clean-bug-report $(BUG_REPORT_DIR) # Ensure the bug_report dir is reset
 	$(GO_TEST_ARGS) $(GO_TEST_USER_ARGS) \
 	$(TEST_PKG)
 
+# https://go.dev/blog/cover#heat-maps
+.PHONY: go-test-with-coverage
+go-test-with-coverage: GO_TEST_ARGS += $(GO_TEST_COVERAGE_ARGS)
+go-test-with-coverage: go-test
+
+.PHONY: validate-test-coverage
+validate-test-coverage:
+	${GOBIN}/go-test-coverage --config=./test_coverage.yml
+
+.PHONY: view-test-coverage
+view-test-coverage:
+	go tool cover -html $(OUTPUT_DIR)/cover.out
+
 #----------------------------------------------------------------------------------
 # Clean
 #----------------------------------------------------------------------------------

README.md

@@ -1,7 +1,7 @@
 
 
 <h1 align="center">
-    <img src="https://github.com/solo-io/gloo/blob/v2.0.x/docs/content/img/logo-gloo-gateway-horizontal.svg" alt="Gloo Gateway v2" width="800">
+    <img src="https://github.com/solo-io/gloo/blob/main/docs/content/img/logo-gloo-gateway-horizontal.svg" alt="Gloo Gateway" width="800">
   <br> 
   An Envoy-Powered API Gateway
 </h1>
@@ -11,89 +11,19 @@
 > **Important**
 > Gloo Gateway is now a fully conformant Kubernetes Gateway API implementation!
 >
-> The existing Gloo Edge v1 APIs were not changed and continue to be fully supported.
+> The existing Gloo Edge APIs were not changed and continue to be fully supported.
 
 ## About Gloo Gateway
 Gloo Gateway is a powerful Kubernetes-native ingress controller and API gateway that is based on the Kubernetes Gateway API. It excels in function-level routing, supports legacy apps, microservices and serverless, offers robust discovery capabilities, integrates seamlessly with open-source projects, and is designed to support hybrid applications with various technologies, architectures, protocols, and clouds.
 
-[**Installation**](https://docs.solo.io/gloo-gateway/v2/quickstart) &nbsp; |
-&nbsp; [**Documentation**](https://docs.solo.io/gloo-gateway/v2) &nbsp; |
+[**Installation**](https://docs.solo.io/gateway/latest/quickstart/) &nbsp; |
+&nbsp; [**Documentation**](https://docs.solo.io/gateway/latest/) &nbsp; |
 &nbsp; [**Blog**](https://www.solo.io/blog/?category=gloo) &nbsp; |
 &nbsp; [**Slack**](https://slack.solo.io) &nbsp; |
 &nbsp; [**Twitter**](https://twitter.com/soloio_inc) |
 &nbsp; [**Enterprise Trial**](https://www.solo.io/free-trial/)
 
-<BR><center><img src="https://docs.solo.io/gloo-edge/main/img/gloo-architecture-envoys.png" alt="Gloo Gateway v2 Architecture" width="906"></center>
-
-## Quickstart with `glooctl`
-Install Gloo Gateway and set up routing to the httpbin sample app. 
-
-1. Install `glooctl`, the Gloo Gateway command line tool.
-   ```sh
-   curl -sL https://run.solo.io/gloo/install | GLOO_VERSION=v2.0.0-beta1 sh
-   export PATH=$HOME/.gloo/bin:$PATH
-   ```
-
-2. Install the Gloo Gateway v2 control plane, and wait for it to come up.
-   ```sh
-   glooctl install
-   ```
-
-3. Deploy the httpbin sample app, along with a Gateway and HTTPRoute to access it.
-   ```sh
-   kubectl -n httpbin apply -f https://raw.githubusercontent.com/solo-io/gloo/v2.0.x/projects/gateway2/examples/httpbin.yaml
-   ```
-
-4. Port-forward the Gateway.
-   ```sh
-   kubectl port-forward deployment/gloo-proxy-http -n httpbin 8080:8080
-   ```
-
-5. Send a request through our new Gateway.
-   ```sh
-   curl -I localhost:8080/status/200 -H "host: www.example.com" -v
-   ```
-
-Congratulations! You successfully installed Gloo Gateway and used an HTTP gateway to expose the httpbin sample app. 
-
-> **Note**
-> To learn more about Gloo Gateway's support for the Kubernetes Gateway API, see the [docs](https://docs.solo.io/gloo-gateway/v2/).
-
-## Quickstart with Helm 
-
-1. Install the custom resources of the Kubernetes Gateway API. 
-   ```sh
-   kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/standard-install.yaml
-   ```
-
-2. Install Gloo Gateway v2. This command creates the `gloo-system` namespace and installs the Gloo Gateway v2 control plane into it.
-   ```sh
-   helm install default -n gloo-system --create-namespace  oci://ghcr.io/solo-io/helm-charts/gloo-gateway --version 2.0.0-beta1
-   ```
-
-3. Verify that the Gloo Gateway v2 control plane is up and running and that the `gloo-gateway` GatewayClass is created. 
-   ```sh
-   kubectl get pods -n gloo-system
-   kubectl get gatewayclass gloo-gateway 
-   ```
-
-4. Deploy the httpbin sample app, along with a Gateway and HTTPRoute to access it.
-   ```sh
-   kubectl -n httpbin apply -f https://raw.githubusercontent.com/solo-io/gloo/v2.0.x/projects/gateway2/examples/httpbin.yaml
-   ```
-
-5. Port-forward the Gateway.
-   ```sh
-   kubectl port-forward deployment/gloo-proxy-http -n httpbin 8080:8080
-   ```
-
-6. Send a request through our new Gateway.
-   ```sh
-   curl -I localhost:8080/status/200 -H "host: www.example.com" -v
-   ```
-
-> **Note**
-> To learn more about Gloo Gateway's support for the Kubernetes Gateway API, see the [docs](https://docs.solo.io/gloo-gateway/v2/).
+<BR><center><img src="https://docs.solo.io/gloo-edge/main/img/gloo-architecture-envoys.png" alt="Gloo Gateway Architecture" width="906"></center>
 
 ### Using Gloo Gateway
 - **Kubernetes Gateway API**: Gloo Gateway is a feature-rich ingress controller, built on top of the Envoy Proxy and fully conformant with the Kubernetes Gateway API.
@@ -113,14 +43,14 @@ C) Allow different teams in an organization choose different architectures. See
 ## Next Steps
 - Join us on our Slack channel: [https://slack.solo.io/](https://slack.solo.io/)
 - Follow us on Twitter: [https://twitter.com/soloio_inc](https://twitter.com/soloio_inc)
-- Check out the docs: [https://docs.solo.io/gloo-gateway/v2](https://docs.solo.io/gloo-gateway/v2)
-- Check out the code and contribute: [Contribution Guides](/devel/contributing)
+- Check out the docs: [https://docs.solo.io/gateway/latest/](https://docs.solo.io/gateway/latest/)
 
-## Thanks
+## Contributing to Gloo Gateway
+The [devel](devel) folder should be the starting point for understanding the code, and contributing to the product.
 
+## Thanks
 **Gloo Gateway** would not be possible without the valuable open-source work of projects in the community. We would like to extend a special thank-you to [Envoy](https://www.envoyproxy.io).
 
 
 ## Security
-
 *Reporting security issues* : We take Gloo Gateway's security very seriously. If you've found a security issue or a potential security issue in Gloo Gateway, please DO NOT file a public Github issue, instead send your report privately to [security@solo.io](mailto:security@solo.io).

changelog/v1.17.0-rc6/backport-recent-changes.yaml

@@ -0,0 +1,25 @@
+changelog:
+  - type: NON_USER_FACING
+    issueLink: https://github.com/solo-io/solo-projects/issues/6026
+    resolvesIssue: false
+    description: >-
+      Introduce code coverage tooling, introduce a basic check on projects/gateway2 tests
+      so that users have some feedback (that is not yet required).
+
+      Update the `devel` folder to remove Gloo Edge references, and replace with Gloo Gateway
+  - type: NON_USER_FACING
+    description: >-
+      Resolve the iosnapshot/history_test flake, by ensuring that asynchronous operations
+      are provided time to complete.
+  - type: HELM
+    issueLink: https://github.com/solo-io/solo-projects/issues/6352
+    resolvesIssue: false
+    description: >-
+      Introduce `gateway.validation.webhook.enablePolicyApi` which controls whether or not RouteOptions and
+      VirtualHostOptions CRs are subject to validation. By default, this value is true.
+      The validation of these Policy APIs only runs if the Kubernetes Gateway integration is enabled (`kubeGateway.enabled`).
+  - type: NON_USER_FACING
+    issueLink: https://github.com/solo-io/solo-projects/issues/6408
+    resolvesIssue: false
+    description: >-
+      Avoid a race condition in the deployer module, but not using a long-lived context.

devel/README.md

@@ -1,15 +1,14 @@
-# Developing Gloo Edge
+# Developing Gloo Gateway
 
-Find tools and information to help you develop the Gloo Edge project.
+Find tools and information to help you develop the Gloo Gateway project.
 
+* `architecture`: Descriptions about high-level design and implementation details of various packages and features.
 * `contributing`: Information to help you contribute to the project, such as how to open issues, review pull requests, generate code, and backport fixes.
 * `debugging`: Troubleshooting steps for debugging frequent issues.
 * `testing`: Descriptions on how the tests work and how to use them.
-* `tools`: A set of scripts and tools that are intended to help you develop the Gloo Edge project's codebase. Learn more about these tools in the short descriptions later in this readme.
-
-_**Note**: For tools that help maintain an installation of Gloo Edge (the product, not the project codebase), build those tools into the [CLI](/projects/gloo/cli) instead._
+* `tools`: A set of scripts and tools that are intended to help you develop the Gloo Gateway project's codebase. Learn more about these tools in the short descriptions later in this readme.
 
 Other resources:
-* [Developer guide](https://docs.solo.io/gloo-edge/latest/guides/dev/) to set up your development environment and learn more about extending the functionality of the Gloo Edge project and related plug-ins. While written for external contributors, internal Solo developers might also find this guide helpful when onboarding.
-* [Product documentation](https://docs.solo.io/gloo-edge/latest/) with guides for end users to use Gloo Edge as a product
+* [Developer guide](https://docs.solo.io/gloo-edge/latest/guides/dev/) to set up your development environment and learn more about extending the functionality of the Gloo Gateway project and related plug-ins. While written for external contributors, internal Solo developers might also find this guide helpful when onboarding.
+* [Product documentation](https://docs.solo.io/gloo-edge/latest/) with guides for end users to use Gloo Gateway as a product
 * [Guide to contribute to the documentation](https://docs.solo.io/gloo-edge/latest/contributing/documentation/)

devel/architecture/endpoint-discovery.md

@@ -1,12 +1,12 @@
 # Endpoint Discovery Service (EDS)
 
 ## Overview
-Envoy supports a variety of mechanisms to configure [Service Discovery](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/service_discovery#arch-overview-service-discovery), the mechanism Envoy uses to resolve the members of the cluster. One of the more complex mechanisms is [EDS](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/service_discovery#endpoint-discovery-service-eds), where the xDS management server (Gloo Edge) provides the Endpoints for a given Cluster via an API.
+Envoy supports a variety of mechanisms to configure [Service Discovery](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/service_discovery#arch-overview-service-discovery), the mechanism Envoy uses to resolve the members of the cluster. One of the more complex mechanisms is [EDS](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/service_discovery#endpoint-discovery-service-eds), where the xDS management server (Gloo Gateway) provides the Endpoints for a given Cluster via an API.
 
-In Gloo Edge, Endpoints can be discovered dynamically via the Endpoint Discovery feature, and then served to the Envoy proxy via the EDS API.
+In Gloo Gateway, Endpoints can be discovered dynamically via the Endpoint Discovery feature, and then served to the Envoy proxy via the EDS API.
 
 ## How it works
-EDS runs in the [Gloo](/projects/gloo) component of Gloo Edge.
+EDS runs in the [Gloo](/projects/gloo) component of Gloo Gateway.
 
 We rely on an [In Memory Endpoint Client](https://github.com/solo-io/gloo/blob/a39fb91c2fb122d5a34353dff891e0b0044bf1dc/projects/gloo/pkg/syncer/setup/setup_syncer.go#L469), meaning that when we “write” an Endpoint, it is just persisted in memory. In Memory clients signal updates to the emitter by two mechanisms: 
 - [timed update](https://github.com/solo-io/solo-kit/blob/1f34a76bf919fd40a50e4504a837ee4b41b7f215/pkg/api/v1/clients/memory/resource_client.go#L238)

devel/architecture/external-options.md

@@ -1,7 +1,7 @@
 # External Options (VirtualHostOption and RouteOption)
 
 ## Overview
-Gloo Edge supports decoupling certain resources from the definitions of options related to the resource. Currently there are two objects which support delegating options definition in this way:
+Gloo Gateway supports decoupling certain resources from the definitions of options related to the resource. Currently there are two objects which support delegating options definition in this way:
 - A VirtualHost (exists on a VirtualService) can be configured with the separate resource [VirtualHostOption](./projects/gateway/api/v1/external_options.proto).
 - A Route (exists on a VirtualHost within a VirtualService or on a RouteTable) can be configured with the separate resource [RouteOption](./projects/gateway/api/v1/external_options.proto).
 

devel/architecture/static_metadata.md

@@ -8,7 +8,7 @@ The [Gloo Proxy Api](https://docs.solo.io/gloo-edge/latest/reference/api/github.
 
 This metadata is not required and the `resourceKind`, `resourceRef.name`, and `resourceRef.namespace` fields which compose the metadata are plain strings.
 
-While the objects used to create the Proxy Api resources are and should be generally irrelevant to the functionality of Gloo Edge, they do provide user facing value as sources of names and labels.
+While the objects used to create the Proxy Api resources are and should be generally irrelevant to the functionality of Gloo Gateway, they do provide user facing value as sources of names and labels.
 
 ## Current uses of this data
 ### Open Telemetry `service.name`

devel/architecture/upstream-discovery.md

@@ -3,10 +3,10 @@
 ## Overview
 A [Gloo Upstream](/projects/gloo/api/v1/upstream.proto) represents a destination for routing HTTP requests. An Upstream can be compared to [clusters](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/cluster/v3/cluster.proto) in Envoy terminology.
 
-Upstreams can either be defined statically in a cluster, or can be discovered dynamically via Gloo Edge's Upstream Discovery feature.
+Upstreams can either be defined statically in a cluster, or can be discovered dynamically via Gloo Gateway's Upstream Discovery feature.
 
 ## How it works
-UDS runs in the [Discovery](/projects/discovery) component of Gloo Edge.
+UDS runs in the [Discovery](/projects/discovery) component of Gloo Gateway.
 
 Create a [discovery emitter](https://github.com/solo-io/gloo/blob/8bbe175ea136178bfe8b4d103ae702d4965c4c75/projects/gloo/pkg/api/v1/discovery_snapshot_emitter.sk.go#L135), which is responsible for the following:
 - Emit a snapshot of the resources that are required for UDS to operate (Upstreams, Secrets, Kubernetes Namespaces)