Includes:
- Improved scannability and organization of checks overview
- Checks overview includes more guidance on
- How to register a health check
- The options available for a health check definition
- Contextual cross-references to maintenance mode
Contains 2 changes to the GetEnvoyBootstrapParams response to support
consul-dataplane.
Exposing node_name and node_id:
consul-dataplane will support providing either the node_id or node_name in its
configuration. Unfortunately, supporting both in the xDS meta adds a fair amount
of complexity (partly because most tables are currently indexed on node_name)
so for now we're going to return them both from the bootstrap params endpoint,
allowing consul-dataplane to exchange a node_id for a node_name (which it will
supply in the xDS meta).
Properly setting service for gateways:
To avoid the need to special case gateways in consul-dataplane, service will now
either be the destination service name for connect proxies, or the gateway
service name. This means it can be used as-is in Envoy configuration (i.e. as a
cluster name or in metric tags).
* Clarify docs around using either Consul or Vault managed PKI paths
The current docs can be misread to indicate that you need both the
Consul and Vault managed PKI Paths policies. The [Learning Tutorial](https://learn.hashicorp.com/tutorials/consul/vault-pki-consul-connect-ca?in=consul/vault-secure#create-vault-policies)
is clearer. This tries to make the original docs as clear as the
learning tutorial
* Clarify that PKI secret engines are used to store certs
Co-authored-by: Blake Covarrubias <blake.covarrubias@gmail.com>
* Clarify transparent proxy documentation
Some confusion over known limitations for transparent proxy, specifically over federation versus cluster peering.
Updated `KubeDNS` to Kubernetes DNS for consistency with Kubernetes documentation.
Co-authored-by: David Yu <dyu@hashicorp.com>
Co-authored-by: Jeff Boruszak <104028618+boruszak@users.noreply.github.com>
This is the OSS portion of enterprise PR 2339.
It improves our handling of "irrecoverable" errors in proxycfg data sources.
The canonical example of this is what happens when the ACL token presented by
Envoy is deleted/revoked. Previously, the stream would get "stuck" until the
xDS server re-checked the token (after 5 minutes) and terminated the stream.
Materializers would also sit burning resources retrying something that could
never succeed.
Now, it is possible for data sources to mark errors as "terminal" which causes
the xDS stream to be closed immediately. Similarly, the submatview.Store will
evict materializers when it observes they have encountered such an error.
Previously, some variables were wrapped in < > while others were not,
creating ambiguity in whether some labels were a string literal or a
variable.
Now, all variables are wrapped in < >.
Adds guidance when upgrading a Consul service mesh deployment to 1.13 and:
- using auto-encrypt or auto-config; or
- the HTTPS port is not enabled on Consul agents
Changes proposed in this PR:
In `actions-docker-build` we [pass](05c370a26e/scripts/docker_build (L49)) `PRODUCT_VERSION` to the docker build command. Since this was not set, the label did not populate properly which is used in a comparison to determine the `minor-latest` and `latest` docker image tags.
How I've tested this PR:
- build the image up to the point of label creation and pass in `--build-arg PRODUCT_VERSION=1.2.3`
- inspect the image for the label with the above command
How I expect reviewers to test this PR:
- same as above
Related [internal-only] post about this: https://hashicorp.atlassian.net/wiki/spaces/RELENG/pages/2416934922/August+17+2022-+Docker+Build+Failures
Dao Thanh Tung