In the metric documentation, some metrics are written with an extra
trailing dot character. Often this is just spurious. In some cases, it
is an allusion to the metric name having various variable dot-separated
parts (which really ought to be labels, but that's another issue).
1) Trim all the dots which are without meaning.
2) Explicitly show with placeholders in angle brackets, where there are
variable parts.
3) Remove a `json` type indicator from a code block which was not JSON
(rather Prometheus metrics) format, since my IDE was reporting the
non-JSON syntax as an error.
4) Reformat each Markdown table which I had touched with other changes
to have consistent column spacing in the source representation. As
a result, this PR has a lot of whitespace changes, so please make use
of GitHub's "ignore whitespace" checkbox in the PR diff viewer.
Let me know if you would prefer:
- to not accept the table spacing reformat in the same PR as other
changes
- to not accept the table spacing reformat ever
- to have all tables in the file reformatted, not just ones touched with
other changes
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.
Max Bowsher