Switch from /v1/agent/self to /v1/status/leader when checking if the test server has come up successfully in the waitForAPI function.
Previously, the test server was relying (probably not intentionally) on the default value of the acl_enforce_version_8 in the TestConfig, which was false. So if you create a test server and enabled ACLs, they would not be enforced and the server would be able to come up pretty quickly because /v1/agent/self would return a 200 status pretty much as soon as the agent is running and most likely before leader election is finished.
Now that we have removed acl_enforce_version_8 property (equivalent to being true by default) if you've created a test server with ACLs enabled, it will need to wait for leader election and for ACLs to be initialized before it'll get a successful response from the /v1/agent/self.
Note: With this change, waitForAPI function no longer requires a 200 response status from the v1/status/leader endpoint. This is because in some tests, namely TestAPI_AgentLeave, we are only running clients, and this endpoint returns a 500 status.
We changed our default definition list layout in
https://github.com/hashicorp/consul/pull/8117.
We replaced the default with a definition-table class but missed one
place where the old default was previously used.
This adds the definition-table class in RTT where it used to use the
default.
* Remove curly brackets and pass through attributes
* yarn upgrade and part manual deps upgrade of non-problematic things
* from-entries from ember-composable helpers receives an array
* PowerSelect destruction bug seems to be fixed upstream
* Ensure all policies have a default 0 date for ember-c-h upgrade
sorting no longer works correctly unless CreateTime has a value
This is instead of having the AutoConfigBackend interface provide functions for retrieving them.
NOTE: the config is not reloadable. For now this is fine as we don’t look at any reloadable fields. If that changes then we should provide a way to make it reloadable.
Instead it has an interface which can be mocked for better unit testing that is deterministic and not prone to flakiness.
# Conflicts:
# agent/pool/pool.go
* ui: Split up client/http and replace $.ajax
This splits the client/http service more in the following ways:
1. Connections are now split out into its own service
2. The transport is now split out into its own service that returns a
listener based http transport
3. Various string parsing/stringifying functions are now split out into
utils
* Remove jQuery from our production build
* Move the coverage serving to the server.js file
* Self review amends
* Add X-Requested-With header
* Move some files around, externalize some functions
* Move connection tracking to use native Set
* Ensure HTTP parsing doesn't encode headers
In the future this will change to deal with all HTTP parsing in one
place, hence the commented out METHOD_PARSING etc
* Start to fix up integration tests to use requestParams
A port can be sent in the Host header as defined in the HTTP RFC, so we
take any hosts that we want to match traffic to and also add another
host with the listener port added.
Also fix an issue with envoy integration tests not running the
case-ingress-gateway-tls test.
PRs #7610 and #7962 changed the locations/URLs for the gateway docs
which results in a HTTP 404 Not Found being returned when accessing
the previous URLs.
Update URLs for gateway docs to point to new URLs.
PR #8243 adds corresponding redirects on consul.io.
* 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.
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.
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.
Alvin Huang
John Cowen
Matt Keeler
Iryna Shustava
Freddy
Matt Keeler
R.B. Boyer
JohnnyB
Kenia
Chris Piraino
Blake Covarrubias
Seth Hoenig