Fixes#7527
I want to highlight this and explain what I think the implications are and make sure we are aware:
* `HTTPConnStateFunc` closes the connection when it is beyond the limit. `Close` does not block.
* `HTTPConnStateFuncWithDefault429Handler(10 * time.Millisecond)` blocks until the following is done (worst case):
1) `conn.SetDeadline(10*time.Millisecond)` so that
2) `conn.Write(429error)` is guaranteed to timeout after 10ms, so that the http 429 can be written and
3) `conn.Close` can happen
The implication of this change is that accepting any new connection is worst case delayed by 10ms. But only after a client reached the limit already.
* Fix typos on commandline flags, updated config opts
- Added anchors to https://github.com/hashicorp/consul/pull/8223
- Fix Typos
Updated to include config file options as well as CLI.
* Upgrade consul-api-dobule to version 3.1.3
* Create ConsulInstaceChecks component with test
* Redesign: Service Instaces tab in for a Node
* Update Node tests to work with the ConsulServiceInstancesList
* Style fix to the copy button in the composite-row details
* Delete helper and move logic to ConsulInstanceChecks component
* Delete unused component consul-node-service-list
In https://github.com/hashicorp/consul/pull/8065 we attempted to reduce
the amount of times that the UI requests the discovery chain endpoint
when connect is disabled on a datacenter.
Currently we can only tell if connect is disabled on a datacenter by
detecting a 500 error from a connect related endpoint.
In the above PR we mistakenly returned from a catch instead of
rethrowing the error, which meant that when a none 500 error was caught
the discovery chain data would be removed. Whilst at first glance this
doens't seem like a big problem due to the endpoint erroring, but we
also receive a 0 error when we abort endpoints during blocking queries.
This means that in certain cases we can remove cached data for the
discovery chain and then delay reloading it via a blocking query.
This PR replaces the return with a throw, which means that everything is
dealt with correctly via the blocking query error detection/logic.
Also fix a bug where Consul could segfault if TLS was enabled but no client certificate was provided. How no one has reported this as a problem I am not sure.
The initial auto encrypt CSR wasn’t containing the user supplied IP and DNS SANs. This fixes that. Also We were configuring a default :: IP SAN. This should be ::1 instead and was fixed.
This provides a user with a better experience, knowing that the command
worked appropriately. The output of the write/delete CLI commands are
not going to be used in a bash script, in fact previously a success
provided no ouput, so we do not have to worry about spurious text being
injected into bash pipelines.
We'd assumed that TTL check outputs shouldn't be shown as it seemed like
they never had outputs, but they can be submitted with notes, which are
then converted into the output.
This unhides the output for TTLs and treats them exactly the same as
other healthchecks.
Fixes#7764
Until now these two fields could only be set through on-disk agent configuration.
This change adds the fields to the agent API struct definition so that they can
be set using the agent HTTP API.
Highlights:
- add new endpoint to query for intentions by exact match
- using this endpoint from the CLI instead of the dump+filter approach
- enforcing that OSS can only read/write intentions with a SourceNS or
DestinationNS field of "default".
- preexisting OSS intentions with now-invalid namespace fields will
delete those intentions on initial election or for wildcard namespaces
an attempt will be made to downgrade them to "default" unless one
exists.
- also allow the '-namespace' CLI arg on all of the intention subcommands
- update lots of docs
Split up unused key validation in config entry decode for oss/ent.
This is needed so that we can return an informative error in OSS if namespaces are provided.
Pierre Souchay