* 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
twunderlich-grapl