Engineering Decisions to Prepare Implementing Design Doc about gateway HOT 9 CLOSED

I've started a document discussing this at https://docs.google.com/document/d/1qeNFfgFJMzVhLhG9l9RgW21THnIA3glgavQhZ3bUFn8/edit?usp=sharing. Let's coordinate there for now and bring things we agree on back to this issue for permanent recording.

from gateway.

+1 on @arkodg's comment. For simplicity, we should go with a single cmd that encapsulates all components.

Otherwise, LGTM!

from gateway.

Thanks @youngnick for creating the doc. @arkodg will run point for Tetrate's input. @alexgervais @LukeShu PTAL at the doc and provide input so we can finalize key technical decisions.

from gateway.

Okay, running through the decisions I listed in the doc so that they are recorded here for posterity. Please feel free to comment with related issues if I miss them.

Local dev and build

• Makefile will be the basis for workflows, be they local dev, CI, or release.
• CI will be done by Github Actions.
• CI will have a unit test run (go test and go test -race)
• The unit test run will use Codecov or similar to track coverage. (This is #74 and #80).
• The Makefile will have targets that will allow us to run the same tests locally, as far as possible.
• There should be a make license target for verifying licensing info.
• CI will also have a linting step. (This is #73).
• CI will have a Gateway API conformance test run, which may be non-blocking to begin with. this is covered by #65).
• We will have a make generate target that updates all autogenerated files, and renders deployment YAMLs, Helm charts and so on. We will also have a CI check for PRs that ensures that this has been run, so PRs can't be merged unless the autogenerated files are up to date.
• We should have a make build target that will build a container and a make push target that will push it to a container registry. This should be overridable with env vars, so that you can set a registry for local dev and push local versions there for local testing. This is covered by #75.
• All build targets should ensure that our software version is set properly in both the binary and container image. Local dev should use a hash for the version.
• We will not use a :latest tag, but instead encourage people to either use a tagged version or main.
• We will have some make targets and tooling to help stand up a local Kubernetes cluster for development, pushing in the current branch's container.

Code layout

• Binaries will be generated from cmd/commandname packages. (#72 started implementing this already).
• Internal packages (not imported outside this repo) will be in internal/.
• Packages that may be exported will be in pkg/.
• The various modes the binary can run in (provisioner, xds-server, anything else) will be implemented as subcommands, so the same container can be used in each case.
• We should use Cobra (https://github.com/spf13/cobra) for command line tooling, and Viper (https://github.com/spf13/viper) for config handling. #72 started already on this front.

Other design decisions

• We will use controller-runtime for goroutine management via the Runnable interface.
• We will use go-control-plane for interacting with Envoy, and push improvements there as required.
• We will aim for incremental xDS from day one, rather than implementing SOTW and building on incremental afterwards.
• We will select a logging framework. #76 covers this work).
• We will strongly encourage users to secure the xds-server <-> Envoy communications with TLS, and ensure that those who do understand that insecure control plane communications are a big security problem.
• We will investigate the best way to provision TLS certificates, and see if we can not have to rely on cert-manager for simple use cases.

Please comment with any issues that are resolving any of these decisions, any concerns you have about them, or anything I've missed.

from gateway.

@youngnick this is a great summary of the decisions from the goog doc. I have a few bits to add:

We will not use a :latest tag, but instead encourage people to either use a tagged version or main.

Instead of main, EG will use of the gateway-dev image. xref: #75 (comment)

• We will strongly encourage users to secure the xds-server <-> Envoy communications with TLS, and ensure that those who do understand that insecure control plane communications are a big security problem.

xref: #70

• We will investigate the best way to provision TLS certificates, and see if we can not have to rely on cert-manager for simple use cases.

xref: #82

As we discussed during the community meeting, the PRs that implement the initial design decisions should start off with a goog design doc detailing the intended implementation.

from gateway.

Code layout

• The various modes the binary can run in (provisioner, xds-server, anything else) will be implemented as subcommands, so the same container can be used in each case.

this sgtm, but im hoping the default documented behavior is all components are enabled using a single command as I mentioned here

from gateway.

#87 follows this desired approach by introducing the serve command to run, manage, etc. EG components.

from gateway.

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

from gateway.

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.

from gateway.