Although the metric is defined, there is no code which ever sets its
value - the code in question is genuinely asymmetric - there are 3 types
of object for which registration can be tracked, but only 2 for which
deregistration can be tracked.
The name of the metric as registered with the metrics library to provide
the help string, was incorrect compared with the actual code that sets
the metric value - bring them into sync.
Also, the help message was incorrect. Rather than copy the help message
from telemetry.mdx, which was correct, but felt a bit unnatural in the
way it was worded, update both of them to a new wording.
This PR covers two sets of changes:
- Documenting the new `destination_peer` for proxy upstream definitions.
- Updating the exported-services config entry documentation.
Updates to the `exported-services` config entry include:
- As of 1.13.0 it is no longer only for Consul Enterprise
- A `PeerName` is now a possible consumer for an exported service.
- Added examples for OSS and Enterprise
- Linked to peering docs
* Docs - k8s - Webhook Certs on Vault
* Adding webhook certs to data-integration overview page
* marking items as code
* Apply suggestions from code review
Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com>
* Updating prerequisites intro
* Updating prerequisites intro
* Updating `Create a Vault auth roles that link the policy to each Consul on Kubernetes service account that requires access` to `Link the Vault policy to Consul workloads`
* changing `Configure the Vault Kubernetes auth role in the Consul on Kubernetes helm chart` to `Update the Consul on Kubernetes helm chart`.
* Changed `Create a Vault PKI role that establishes the domains that it is allowed to issue certificates for` to `Configure allowed domains for PKI certificates`
* Moved `Create a Vault policy that authorizes the desired level of access to the secret` to the Set up per Consul Datacenter section
* Update website/content/docs/k8s/installation/vault/data-integration/webhook-certs.mdx
Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com>
* Moving Overview above Prerequisites. Adding sentence where missing after page title.
* Moving Overview above Prerequisites for webhook certs page.
* fixing the end of the overview section that was not moved.
Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com>
Having this type live in the agent/consul package makes it difficult to
put anything that relies on token resolution (e.g. the new gRPC services)
in separate packages without introducing import cycles.
For example, if package foo imports agent/consul for the ACLResolveResult
type it means that agent/consul cannot import foo to register its service.
We've previously worked around this by wrapping the ACLResolver to
"downgrade" its return type to an acl.Authorizer - aside from the
added complexity, this also loses the resolved identity information.
In the future, we may want to move the whole ACLResolver into the
acl/resolver package. For now, putting the result type there at least,
fixes the immediate import cycle issues.
This is only configured in xDS when a service with an L7 protocol is
exported.
They also load any relevant trust bundles for the peered services to
eventually use for L7 SPIFFE validation during mTLS termination.
trujillo-adam