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.
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.
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.
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.
The removeDups template function converts a slice into a map and
back into a slice in order to leverage the map keys to remove
duplicates. However, since the iteration order over a map is not
specified it would be possible to get different orders for multiple runs
of `make api`. While this would not have an impact on any functionality,
it is causing sporadic failures for the new make-gen-deltas CI job.
See: https://go.dev/ref/spec#For_statements
Ref: d57603022a
Passthrough args looks for the an instance of -- and re-slices the arg
list to pass through those args to the underlying connect exec command.
However such commands may also need to parse their own '--', such as
kubectl exec.
This change updates the logic so that boundary arg parser only considers
the first instance of '--' when deciding which args to pass to the
-exec= commands.
Fixes: #1857
* fix(controller/targets): authorize-session should allow h_ ids
The targets controller previously only allowed hosts from a static catalog
since it checked for the ID subtype from the static package.
This change validates host ids with the plugin.Subtype as well
Fixes: #1850
* test: cover authorize-session with host id
Add a regression test to cover the case where an explicit host ID was
given when calling AuthorizeSession
When creating the options for the preferencer, this used WithIpAddrs for both the host addresses and also DNS names. This causes errors when a host contains DNS names that are not IP addresses (ie: whenever dns names are present).
This change will:
- Replace WithIpAddrs with WithDNSNames option for DNS Names when constructing options for the preferencer.
- Add a test which includes a DNS name to prevent regressions
Fixes#1848
* feat(host): Add host set information to static host
Updates LookupHost and ListHost API to include sets a static host is part of, as like with plugin hosts.
* test: updated TestList_Plugin and TestCrud to be more consistent under race conditions
* Make it clear in the subcommands that the given strings are examples
* Add an OIDC example to show that there are different types
* Remove password flag from examples
Jeff Mitchell
A-440Hz
ToddandHugo Vieira
Lars Lehtonen
irenarindos
Johan Brandhorst-Satzkorn
Timothy Messier
Louis Ruch
Irena Rindos
Justen Walker
Carlos Alcaide Corvo