* Have fallback eventing use json format
The server will initialize a logger via InitFallbackLogger(...)
after setting up the server's logging (and honoring the related
cmd flags). This fallback logger will be used if when no eventer
is initialized.
If no fallback logger is initialized, then a event.defaultLogger() will
be used if no eventer is defined.
Co-authored-by: Jim <jlambert@hashicorp.com>
Right now there is a bit of a race condition in that a status call that
indirectly tells the controller that a worker is ready to accept
sessions can have its response unable to be processed in time for an
actual session to come in from a client. It's very unlikely but
technically there.
This changes where we check if we have ever successfully authenticated
from the function called by the ticker to the ticker itself, allowing us
to reset the timer to a very short time if we have not yet
authenticated. We already have the initial timer set to 0 for "as soon
as possible" behavior, but if that initial status failed we'd wait for
the normal interval. Now we will instead continue with the "as soon as
possible" behavior, and reduce the very unlikely race condition to
extremely unlikely.
(There are more permanent fixes but those are bigger and can come
later.)
This adds two new config options for the `database` stanza:
- `max_idle_connections`
- `max_idle_time`
These correspond to settings for the underlying `sql.DB` instance. They
can be used to have finer control over the controller's database
connection pool. For example this can be used to mitigate the high
connection overhead when connecting to postgres by setting a high
`max_idle_connections` and either setting `max_idle_time` to zero or to
a high duration.
Alternatively, if using a connection pool like pgpool-II or pgbouncer,
`max_idle_connections` can be set to 0.
See:
https://pkg.go.dev/database/sql#DB.SetMaxIdleConnshttps://pkg.go.dev/database/sql#DB.SetConnMaxIdleTimehttps://www.pgpool.net/mediawiki/index.php/Main_Pagehttps://www.pgbouncer.org/
* bug(scheduler): Fix controller id length check
The job_run table has a foreign key to the server_controller private_id.
While this column is called a prviate_id it does not implement the wt_private_id
postgres domain type, and therefore does not have a minimum length of 10 characters.
This introduces two changes to reduce the output of tests in CI and for
local developers:
- Silences gorm db logs
- Silences log indicating the lack of an eventer
This removes a lot of log clutter from normal test execution with `go
test -v`. There are a number of test that expect no results from the
database or other error cases from the database. The previous default
log level of dbw.Error would cause these cases to generate logs in the
success case, creating noise in the test output.
The new default for tests is dbw.Silent. This can be overriden in two
ways. A test can be updated to pass in the db.WithTestLogLevel option,
which allows for targeting specific tests to include additional output.
This may make sense for tests that normally should not cause errors, but
would report an error if it fails.
Alternatively a new environment variable can be set,
DEFAULT_TEST_LOG_LEVEL. This allows for adjusting the log level without
changing any test file. The environment variable should be set to the
string value of the log level, and is treated as case insensitive, ie:
export DEFAULT_TEST_LOG_LEVEL="error"
If a worker starts up and tries to connect to a controller before the
controller has a chance for its rotate roots job to run, it'll spit out
a nasty-looking error. It's harmless (things just retry and then work)
but scary (`tls: internal error`).
Rotating at creation time ensures that it's ready by the time a worker
is able to perform any connection against the cluster port.
Haotian
Loann LeandRobin Beck
Michael Gaffney
Jeff MitchellandJim
Johan Brandhorst-Satzkorn
Todd
Danielle Miu
Jeff Malnick
Timothy Messier
Carlos Alcaide Corvo
Damian Debkowski
Louis Ruch
Sam Salisbury
Michele Degges
Cameron Perera
Dharini Jeeva