* fix state index for `CAOpSetRootsAndConfig` op
* add changelog
* Update changelog
Co-authored-by: Daniel Nephin <dnephin@hashicorp.com>
* remove the change log as it's not needed
Co-authored-by: Daniel Nephin <dnephin@hashicorp.com>
The ServiceChecks parameter was incorrectly documented in e515c9d44 to
state that it accepted a list of string values, when actually the API
requires an array of ServiceCheck objects.
This commit updates the docs for the parameter to correctly reflect
the fields required by the API.
Resolves#10752
The ServiceChecks parameter was incorrectly documented in e515c9d44 to
state that it accepted a list of string values, when actually the API
requires an array of ServiceCheck objects.
This commit updates the docs for the parameter to correctly reflect
the fields required by the API.
Resolves#10752
Add a note to the docs for the service defaults config entry which
informs users that the service protocol can be configured for all
services using the proxy defaults config entry.
Resolves#8279
Co-authored-by: Freddy <freddygv@users.noreply.github.com>
Add a note to the docs for the service defaults config entry which
informs users that the service protocol can be configured for all
services using the proxy defaults config entry.
Resolves#8279
Co-authored-by: Freddy <freddygv@users.noreply.github.com>
Document the namespace parameter can be specified on HTTP Check,
Connect CA leaf, and Discovery Chain API endpoints.
Co-authored-by: Freddy <freddygv@users.noreply.github.com>
Document the namespace parameter can be specified on HTTP Check,
Connect CA leaf, and Discovery Chain API endpoints.
Co-authored-by: Freddy <freddygv@users.noreply.github.com>
The base64 CLI utility has two different short flag arguments for decode
depending on the platform: -D and -d.
Previously, the docs used the -D flag exclusively with the base64 utility.
Luckily, the long form of the flag is the same across platforms: --decode.
All uses of the base64 -D flag have been replaced with --decode.
Knowing that blocking queries are firing does not provide much
information on its own. If we know the correlation IDs we can
piece together which parts of the snapshot have been populated.
Some of these responses might be empty from the blocking
query timing out. But if they're returning quickly I think we
can reasonably assume they contain data.
* return an error when the index is not valid
* check response as bool when applying `CAOpSetConfig`
* remove check for bool response
* fix error message and add check to test
* fix comment
* add changelog
Update output for /v1/session/ endpoints to match output post Consul
1.7.0.
Documents new `NodeChecks` and `ServiceChecks` parameters which were
added in that release.
Resolves#7341, resolves#10095
Update output for /v1/session/ endpoints to match output post Consul
1.7.0.
Documents new `NodeChecks` and `ServiceChecks` parameters which were
added in that release.
Resolves#7341, resolves#10095
If multiple instances of a service are co-located on the same node then
their proxies will all share a cache entry for their resolved service
configuration. This is because the cache key contains the name of the
watched service but does not take into account the ID of the watching
proxies.
This means that there will be multiple agent service manager watches
that can wake up on the same cache update. These watchers then
concurrently modify the value in the cache when merging the resolved
config into the local proxy definitions.
To avoid this concurrent map write we will only delete the key from
opaque config in the local proxy definition after the merge, rather
than from the cached value before the merge.
trujillo-adam