* Add generic read/update/delete commands
This adds three generic commands that use the resource prefix to
determine the subcommand to run and pass through args over to that
subcommand. Since this occurs very early on and to avoid loading
essentially every internal resource package, I moved subtype definitions
to globals.
* Update main.go
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
* Update changelog and remove another deprecated command
---------
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
The Vault Credential Store only accepts Vault tokens that have a TTL
greater than the internal job scheduler's run frequency. This prevents a
Vault Credential Store from being created with a Vault token that will
expire before Boundary can renew it.
The Vault test server, by default, creates Vault tokens with a TTL equal
to the duration of time remaining until `t.Deadline()` is reached.
This change sets the test controller's default job scheduler duration to
be half of time remaining until `t.Deadline()`. The default job
scheduler duration can still be overridden by setting a duration on
`TestConrollerOpts.SchedulerRunJobInterval`.
This change fixes the error received when running:
go test -timeout 30s \
-tags devlicense \
-run '^TestList$' \
github.com/hashicorp/boundary/internal/tests/api/credentialstores
Which returned this error:
{"kind":"Internal",
"message":"credentialstores.(Service).createInRepo: unable to create
credential store: vault.(Repository).CreateCredentialStore: unknown,
unknown: error #0: scheduler interval must be greater than token
ttl. scheduler jobs interval value: 1m0s"}
In #2076 the refactor changed the position of a parenthesis, causing
the dev key to truncate the base64 representation instead of specifying
which bytes to base64 encode.
We don't need this slicing anymore anyways since we now do individual
key generation calls so just remove it.
The TestObject test helper previously returned an error,
but it's easier to have it perform the error check itself,
as it conventionally done with test helpers.
* test(e2e): Add test for controller led worker registration
* chore(e2e): Rename log files to ensure uniqueness
This updates the log files to be based on the scenario name instead of just the test package in case some scenarios run the same test package
This is a lint error but wasn't caught because it was a
historic problem. It's appearing again now because we're
adding another method to this type as part of the
pagination workflow.
When generating the JSON for submitting the github comment, if the
message was too large, the workflow would fail with the following error:
/usr/bin/jq: Argument list too long
This fix switches to using the `--rawfile`, which allows jq to process
the large comment.
* fix: monitorUpstreamConnectionState CPU consumption
`monitorUpstreamConnectionState()` is a goroutine that listens for GRPC client connection changes using GRPC's `WaitForStateChange` method. `monitorUpstreamConnectionState()` was consuming the a lot of CPU. It was continuously running and not actually waiting for state changes. The `state` for `monitorUpstreamConnectionState()` was not getting correctly updated which caused the loop to continuously run instead of waiting for new state changes.
Update GRPC `WaitForStateChange` method to use the same `state` that gets updated.
We inadvertently used
kms.GetWrapper(ctx, am.ScopeId, kms.KeyPurposeDatabase)
which resulted in the use of a database key for an oplog entry.
See:
https://github.com/hashicorp/boundary/pull/3665/files#diff-bcf83b5283886c98fc45b6435fdc94d87d545b2768c6beac8acd14eb9d6b13f1
This fixes the issue with the missing "Database" purpose key when
we converted the oplog keys into their own tables.
We chosen to truncate the existing oplog entries to eliminate any
references to a Database kms key in existing oplog entries.
In preparation for putting proxy code in the api package this creates some necessary fields in the target output and it pre-moves credential parsing and proxy handshake code to their new places. This will make the diff for the actual proxy code move quite a bit smaller.
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
gRPC v1.58.3 fixes a vulnerability in the HTTP stack where a malicious
HTTP/2 client which rapidly creates requests and immediately resets them
can cause excessive server resource consumption.
See https://github.com/grpc/grpc-go/pull/6708 for more details.