v0.4.2 is the latest Gateway AP release. Should this release be used or should the main branch be used until v0.5.0 is released which introduces release channels?

cc: @youngnick

#16 specifies the need for a Gateway API Translator (GAT) to decouple the user APIs from the internal system. The GAT details should be captured in this issue or a linked doc.

#16 specifies the need for a Path Watcher (PW) component to allow EG to be configured from file(s) in a directory path. The PW details should be captured in this issue or a linked doc.

I added an "About" and topics to the repo homepage, PTAL. This issue captures the need for both. @arkodg @youngnick @skriss @LukeShu @alexgervais please comment in this issue with any "About" or topics suggestions.

During the 4/29/21 community meeting, support for L4 support, e.g. TCPRoute was discussed. The community should come to an agreement on if L4 should be supported and if so, how.

Create initial integration/e2e tests, framework, tooling etc. that exercises the EG codebase.

As discussed, the repo can use additional labels to help organize PRs, issues, etc. After reviewing other projects in the envoyproxy org, the following are the labels that I propose:

area/ci
area/build
area/api
area/config (Config Manager, Config Sources, etc.)
area/data model
area/message service
area/translator
area/xds server
area/provisioner

@arkodg @LukeShu @alexgervais @youngnick @skriss PTAL at the above list, provide feedback, and any add'l labels that you feel are needed to kickoff the project.

As a Kubernetes cluster administrator, I would like Gateway to support Kubernetes services that run in multiple clusters. Gateway should support multi-cluster service networking methods defined by sig-multicluster but not preclude other methods.

xref: #7

#16 specifies the need for an xDS server to configure managed Envoy instances. The xDS server details should be captured in this issue or a linked doc.

To simplify the UX (especially for dev's), the project should support managing a default GatewayClass and Gateway. For example, when EG is started with an ENV var or CLI flag such as --default-gateway-class=true and --default-gateway=true it will create the default GatewayClass and default Gateway resources.

Open Questions:

1. What namespace should be used for the default Gateway? To support the most simple use case, the default namespace can be used? If the Gateway is created in the EG system namespace, then the default Gateway needs to support cross-namespace routing as this ns is not meant for proxied apps, xref.
2. Should EG support active management of these resources, e.g. someone deletes the default Gateway and EG will recrate it.
3. Other considerations?

A Config API is required for EG to consume config params through gatewayclass.spec.parameterRefs. This config API is referred to as "Bootstrap Config" in #16.

The readme should be updated to xref cncf/envoy public announcements.

Envoy Gateway intends to support upstream services & endpoint running in all environments as highlighted here. This issue tracks how this can be
achieved using the Gateway API

Use Envoy contrib guide as a reference model.

High-level dev workflow:

• Create issue
• Label issue accordingly
• Create a local topic branch
• Hack and commit changes, include a --signoff for each commit.
• Push commits to repo branch
• Submit PR to main, include fixes <issue_number>.
• Other?

#16 specifies the need for a Message Service (MS) component to allow internal services to communicate while being loosely coupled. The MS details should be captured in this issue or a linked doc.

Create a CHANGELOG.md file at the repository root to document changes and release notes.

#16 specifies the need to define APIs, e.g. bootstrap config. To begin developing these APIs, the community should agree on:

1. How these APIs will defined, protos vs Go types. Emissary uses protos to define API types whereas Contour uses Go types.
2. How these APIs will documented.
3. How these APIs will be maintained.
4. Others?

Create a Readme that provides an intro to the project and references on how to communicate with the community, how to contribute, etc.

#16 states that EG will merge config from multiple sources but does not provide the "how". This "how" should be detailed in this issue or a referenced design doc.

Users might want to directly configure xDS Resources in case Envoy Gateway's API doesn't support their use case.
They might want to add/merge/remove/replace xDS resources that are pushed by Envoy Gateway into Envoy Proxy.
Projects such as Istio provide APIs such as EnvoyFilter to fulfill these use cases.

Outlining work items

• Define and Design API #1410
• Implement API in the Xds Translator #1606
• Implement support in egctl for offline verification #1682
• Add status to Policy to show runtime status #1691
• E2E #1738
• Docs #1733

A docker hub repo is needed to store EG images. The push will be triggered by a GH action.

The initial governance doc is generalized. Update the doc to include more procedural information.

xref: #58

The following checklist must be completed for the project's public announcement, e.g. v0.0.1:

• Merge required PRs: Readme, Goals, Design (add others if needed).
• Remove the private CNCF Slack channel and create an Envoy public channel.
• Create and post an official Envoy announcement (@mattklein123 owner).
• Create a public Docker image repo. This can be completed post-announcement since the code will be demo only.
• Complete repo bootstrapping, xref.
• Others?

A matrix is needed that describes component versions used in EG releases. For example, EG v0.1 = Envoy v1.x, Gateway API v1.y, etc.

Enumerate the engineering decisions needed to prepare for implementing the design doc.

Port Gateway API code from Contour to provide a kubecon demo. The code should be ported to a demo branch and not main. The ported code should be as minimal as possible to demo Gateway API functionality.

A document about the project roadmap helps users understand

• WHAT - future scope and deliverable for the project
• WHEN - timelines for delivering these milestones / also helps with GH project visibility
• HOW - procedure for users to request & upvote new items into the roadmap

The community has established Gateway API conformance as the target of the 0.0.2 release. This is a meta issue, in that issues, PRs, etc. that target this goal should be linked to this issue.

The project is currently targeting the edge reverse proxy use case. Should the project also support forward proxy, e.g. egress?

Create a GOALS.md document that highlights the objectives, non-objectives and personas of the Gateway project.

#16 specifies the need for a Provisioner to manage the infra needed to run Envoy. The Provisioner details should be captured in this issue or a linked doc.

Istio Ingress Gateway is an Envoy-based edge proxy that is managed by Istiod and integrates with the Istio service mesh. Should EG be considered as a replacement? If so, why? What are the benefits of using EG for mesh ingress instead of Istio Ingress Gateway? Do other opportunities exist to integrate with Istio?

Consider defining a WASM ABI spec for Control Plane APIGateways similar to proxy-wasm so the components defined in #16 can be extended by users to define new control plane APIGateway functionality . wazero might be an apt runtime to use.

#16 specifies the need for a Service Resolver (SR) component that resolves IR services into platform-specific endpoints. The SR details should be captured in this issue or a linked doc.

1. What are the steps for releasing EG? Automate as much as possible, e.g. GH actions, etc.
2. At what cadence should EG be released? I suggest we sync with Envoy proxy releases, targeting v1alpha for 7/15/22, xref.
3. Assign a release manager or create a release manager rotation.
4. What artifacts should be released?
5. Decide on release numbering, e.g. should this project follow Envoy's release numbers?
6. Where to store the EG image (xref #14)?
7. How should the EG image be tagged?
8. Should GH projects, milestones, etc. be used for managing releases?
9. Other considerations?

Create a design document that provides details of system components, functionality, etc.

#16 specifies the need for a Config Server (CS) component to allow EG to be configured from a remote endpoint. The CS details should be captured in this issue or a linked doc.

#16 specifies the need for an Intermediate Representation (IR) component to decouple the system from Gateway API. The IR details should be captured in this issue or a linked doc.

The Config Manager is responsible for instantiating and managing the lifecycle of the various system components
in Envoy Gateway based on the Envoy Gateway Bootstrap spec

IMO "Gateway" does not accurately reflect the intended functionality of the project. The project will manage Envoy fleets that are represented as GatewayClasses and Gateways. Let's use comments in this issue to provide name suggestions and a thumbs-up emoji if you like the name. The name with the most thumbs-up's wins. If a tie exists, we'll have @mattklein123 be the final decision maker.

The file should list the maintainers of the project.

#24 highlights the need for users to override xDS resources configured by
Envoy Gateway. Raising this issue to track how do you express this intent for the Envoy Proxy Bootstrap Config using the Gateway API

here's how popular OSS projects do it

• Istio - this & this
• Contour allows the user to attach a new bootstrap file
• Emissary allows the user to override a subset of the bootstrap resources

Updated

• Design doc #1070
• API Design #1070
• EnvoyProxy Bootstrap validation #1109
• Implement API #1094
• Update GatewayClass Status based on EnvoyProxy validation #1107
• Implement egctl subcommand to generate default bootstrap #1281
• Docs #1333

Should Envoy Gateway's documentation be separate from Envoy's official docs or integrate with https://github.com/envoyproxy/envoy-website

#16 specifies the need for an xDS Translator (XT) to translate IR resources to an xDS config. The XT details should be captured in this issue or a linked doc.

• Define Bootstrap Config API
• Add infra to define API and generate go structs

We need to make sure we have some sort of code of conduct markdown file in the root of the repo.

Serverless is becoming a common app runtime for cloud native apps. Popular Serverless OSS projects such as Knative should use EG as the preferred ingress/egress networking solution.

Create an initial CI environment where TBD tests are executed for PRs.

A GOVERNANCE.md is required to explain how to become a maintainer, maintainer responsibilities, etc.

xref: #3

• Readme
• Contrib guide
• Design doc
• Code of conduct doc
• Owners doc
• Goals doc
• Governance doc

envoyproxy/envoy repo should be used as a reference for how docs are created for this repo.