There was a misunderstanding of how goroutines work. Turns out, the goroutine uses the same keyring as the main routine, which can result in some conflicts depending on when the goroutine executes
Rearranges the directory structure to align better with the enos scenarios. Tests will now be added in the `tests` directory, with a folder in the directory corresponding to an enos scenario.
The "can not read deleted $NEW_STORE static store" bats test was demonstrating flaky behavior where it would fail due to the credential store read still returning something valid. This check has been moved to an e2e test in order to add some retry logic to the check.
Many tests had duplicate code to create the base level domain objects in a boundary environment. This commit refactors that code to use functions for these commonly used operations.
feat(config): Support multiple files
This updates the three subcommands that take a `-config` flag to
to support multiple config files via a repeated `-config` flag.
It updates the following subcommands:
- `server`
- `database init`
- `database migrate`
Note that the multiple file support only works if all config files are
HCL, not JSON. Also note that the config files are concatenated
together. There is no attempt to merge config files, so having the same
stanza in multiple files can yield unexpected results, with only one of
the stanzas being used.
When used with these limitations understood, this provides a way to take
different actions for different kinds of dynamic configuration changes.
An example would be when using consul-template to render the
configuration files for boundary. With the multi file support
consul-template can render one config file for the controller stanza,
and provide boundary with a dynamic database credential via vault. Then
when the credential is rotated, consul-template can send boundary a
SIGHUP to switch to the new credential without a restart. A separate
template could be used to render a config for a stanza that does not
support SIGHUP, such as the events stanza that gets its values via
consul's KV. If these values change, consul-template can restart
boundary so the new configuration is used.
Co-authored-by: Timothy Messier <tim.messier@gmail.com>
Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com>
This adds a context to the session.RepositoryFactory, allowing
errors.NewDeprecated to be replaced with errors.New. It also removes the
common.SessionRepoFactory, instead packages just directly import from
the session package.
* feat(sql): Fork pgtap to support arm64
This forks pgtap-docker and builds the image locally,
and updates our references to use our forked image.
* fixup! feat(sql): Fork pgtap to support arm64
* Remove the server_id from session table, change it to worker_id on session_connection
This is step 1 in updating the worker table. The worker is becoming a public resource so it must have
a public id. We drop the server_id column on the session_connection table and add the worker_id column
so we can use the wt_public_key type. Since db migrations are applied while the controller is offline,
it should be safe to assume all session connections are not in a running state, thus allowing us to null
out all the worker ids in the session_connection table.
For now we don't have very good enforcement of the wt_public_id constraints, since the id is currently
defined in the worker config, but this will soon change and the worker's id will be generated by the
controller.
* Remove the server_id from session table, change it to worker_id on session_connection
This is step 1 in updating the worker table. The worker is becoming a public resource so it must have
a public id. We drop the server_id column on the session_connection table and add the worker_id column
so we can use the wt_public_key type. Since db migrations are applied while the controller is offline,
it should be safe to assume all session connections are not in a running state, thus allowing us to null
out all the worker ids in the session_connection table.
For now we don't have very good enforcement of the wt_public_id contraints, since the id is currently
defined in the worker config, but this will soon change and the worker's id will be generated by the
controller.
* Updating server_id references to controller_id.
* Adding worker tag db writing test.
* Move the server table back to the top.
* Update comment for the worker object.
* Update comment for the worker table.
* Update the newWorkerId call to take a context and fix its error.
* Correct comment for the wt_network_address domain.
* Remove the server_id from session table, change it to worker_id on session_connection
This is step 1 in updating the worker table. The worker is becoming a public resource so it must have
a public id. We drop the server_id column on the session_connection table and add the worker_id column
so we can use the wt_public_key type. Since db migrations are applied while the controller is offline,
it should be safe to assume all session connections are not in a running state, thus allowing us to null
out all the worker ids in the session_connection table.
For now we don't have very good enforcement of the wt_public_id constraints, since the id is currently
defined in the worker config, but this will soon change and the worker's id will be generated by the
controller.
* Move the server daemons into their own package
With this change the internal/server package now is dedicated to the server domain (workers and controllers) and not to the server daemons.
The hope is that this will make it easier to keep the daemons decoupled from the representation of the servers in the database.
Michael Li
Johan Brandhorst-Satzkorn
Timothy MessierandJeff Mitchell
Damian Debkowski
Todd
irenarindos