This allows us to use SNI for actual host (e.g. routing) information. We
don't have the client cert yet so we can't look at that, so this
provides a way for us to convey the information needed to look up that
session's TLS stack.
Using SNI for hosts means we also run into the fact that we don't have
automatic agreement in terms of SANs. So when generating the certs we
now also pass worker address information to the function to be encoded
in the cert.
Finally, there is a change in how the websocket dialing happens, because
http.RoundTripper tries to be too clever for its own good and overwrites
NextProtos on a whim.
We never ended up using this and it makes it much harder to reason about the listeners.
An explanation: for the moment I separated out all of the listeners in the struct, even though one should suffice, because when I did it that way first I was hitting some really weird and hard to find intermittent behavior where it seemed like the listeners were getting crossed. So I re-did it this way with each listener very explicitly referenced. I'm happy to make a follow-up PR that attempts to combine them all into a single listener without hitting the issues I did, if desired, but at least doing it via a separate PR means that it won't be something with removing the ALPN muxer that is at fault.
Use the standard Go heuristic for determining
whether a file should be ignored by formatting
for being a generated file.
This is effectively a no-op change today, but
if we add new generated files in the future,
we should automatically ignore them in formatting.
This is a slightly updated version of #1941 that should
work across all versions of grep.
This change introduces a `nonceFn` field that can be changed
by a test but at runtime is transparent to the code that calls it.
The current nonce-generating logic defaults to a test-only field which
opens us up to this value inadvertently being set.
With this change, the default behavior becomes using `base62` to
generate a random nonce, and any tests have to explicitly change that.
With this change, the Worker is now aware of its own listeners in a
more codified and structured way.
These changes have already been made in the controller on
8d48a8515c. They're now made on the
worker for similar reasons.
* feat(controller): New health service and server
This change also implements a new listener purpose, `ops`.
`ops` (short for operations) is a new listener purpose that is
responsible for serving Boundary's operations endpoints, like health
and possibly metrics.
At Startup: `ops` listeners get configured as late as possible to catch
any errors with the startup process;
At Shutdown: If the health endpoint has been set-up, we introduce a
configurable delay in the process. This is to enable the health endpoint
to report unhealthy for that amount of time. `ops` listeners are also
the last listeners to be shutdown.
Use the standard Go heuristic for determining
whether a file should be ignored by formatting
for being a generated file.
This is effectively a no-op change today, but
if we add new generated files in the future,
we should automatically ignore them in formatting.
In general, these changes were introduced in the same vein of the
changes to controller `startListeners`.
Specifically, these changes also decouple the Controller and the Worker
shutdown processes. Currently, a call to `stopListeners` on an instance
that is running as both a Controller and a Worker would stop the
listeners for both.
Lastly, we also add unit/integration tests to the shutdown code.
* Revert version upgrade of dbus and go-keyring
The combination of these versions were causing build errors on freebsd
* Only revert zalando/go-keyring
Previously, we initialized the listeners on the order they were provided
to us on the config file. In the future, we'll want to add new listener
purposes that depend on existing ones, so the init order needs to be
deterministic.
With this change, we'll initialize components in this order:
1. gRPC Server for Controller API.
2. All `api` HTTP Servers & gRPC Gateway Muxes.
3. `cluster` gRPC Server.
This commit introduces some renames for the sake of clarity as well as
improved test coverage:
- Removes `gatewayMux` reference from Controller object. This object was
misleading and is now uneeded.
- Removed uneeded `context.Context` arguments.
- Separates gRPC Server and gRPC Gateway concerns, both in functionality
and in naming. These two were conflated before.
- Added unit tests on `startListeners`.
With this change, the Controller is now aware of its own listeners in a
more codified and structured way.
The reasoning behind these changes are as follows:
1. Currently, we're iterating over these listeners in multiple spots
along this initialization flow to check each listeners' purpose. By
doing this once when we create a Controller and essentially storing the
result, we can clean up the downstream code to use those results.
2. Initial effort to centralize Controller validation. At the moment, we
are doing a lot of validation all over the `cmd` and `config` packages.
From a conceptual perspective, Controller-related validation should
be performed in the function that is responsible for constructing the
Controller object itself. This enables any developer to look in a
single place for all the constraints that we place on creating a
Controller.
This contains to related things:
1. An adapter allowing an hclog interface to take in information and send them to the eventer
2. A gate on the eventer, which is the analogue to the behavior prior to eventing where we'd ensure logs were not printed prior to the startup information. Without this, plugin logs using the hclog adapter will start showing up too early.
This removes or reduces the time that is waited in a number of tests by
allowing the grace period time be a configuration option on the
connection repository.
This creates a domain service function `session.WorkerStatusReport`. The
service performs two functions:
1. Checks the status for all of the reported sessions, returning a
report of the sessions that are in a "non-active" state, i.e.
"cacneling" or "terminated".
2. Looks for any "orphaned" session connections, i.e. connections that
are active but were not reported by the worker. These connections are
marked as closed.
This also removes the "ShouldCloseConnectionsOnWorker" logic, as this
was determined to not be a possible state, and was unnecessary.
The query for CloseDeadConnectionsForWorker includes a time comparison
to exclude results that are too close to the current time. This is done
to account for a delay in reporting by the worker. However, since the
delay was hardcoded in the query, it made it difficult to test.
This moves the delay duration into a parameter that is set on the
repository. The amount of the delay can be set at repository creation
time using the new WithWorkerStateDelay option. This defaults to the
previously hardcoded amount.
This will allow tests to control the delay to exercise this
functionality fully.