Don't error in ReleaseGate if the context used for the original
event has been cancelled. Any error in ReleaseGate causes the
controller to terminate its startup. If a user was trying to send
a request to the Boundary controller as it started up, the context
tied to the request would be reused to attempt logging the
observation associated with the request after the logging gate
was released. This would always fail, as the context associated
with the request was canceled.
We now use a new context timeout for events logged after the release
gate is released, if the original context was canceled.
* Update release dir owner group
The old group only contains a service account. I updated it to the self managed release engineering group instead.
* Remove release engineering as code owners
Actually lets just remove this group, as per their justification in #4057
* Result of tsccr-helper -log-level=info gha update -latest .github/
* chore: Fix usage of slack-github-action
---------
Co-authored-by: hashicorp-tsccr[bot] <hashicorp-tsccr[bot]@users.noreply.github.com>
Co-authored-by: Michael Li <michael.li@hashicorp.com>
* Refactor redundant append operations in test setup
- Simplified code by removing unnecessary if-else conditions in the wantUserIds and wantGroupIds blocks.
Fixes#5205
* chore: fmt fix
Previously, if one of these tests failed to start their servers before
the timeout, there was a risk that the goroutine started to run
the server would invoke t.Errorf after the test itself had concluded.
Replace t.Errorf with fmt.Printf to avoid the panic, and include
the test name for debugging.
* chore(e2e): Update to use t2.small instances
Using the updated AWS SDK required more memory and was causing workers to crash.
* chore(e2e): Add identifier to aws instance
* internal/handlers/managed_groups: ensure membership lookup is unlimited
Previously, we would only show the first 10,000 members in the group,
giving the impression that a complete list was performed. Now we
list all members.
* internal/handlers/accounts: ensure group lookup is unlimited
Previously, we would only show the first 10,000 managed group
memberships. Now we list all group memberships of an account.
Previously, we would list the managed groups with an implied
filter of db.DefaultLimit (10,000), which would incorrectly remove
a user from managed group memberships if there were more
than 10,000 managed groups in an auth method. Explicitly
set the list limit to unlimited to ensure all managed groups are
updated appropriately.
This commit changes the logic around selecting jobs to run. Before this,
Boundary used a view "job_jobs_to_run" which was a collation of all jobs
that were not running and scheduled to run. When jobs were requested to
run, Boundary would look at this view, grab a certain amount of jobs and
insert them into the "job_run" table. Importantly, while the amount of
jobs to be scheduled at once defaulted to 1 in the scheduler package,
this was entirely overriden in the controller package to -1 (no limit,
run all jobs that the query would return).
With this commit, Boundary now looks at the "job" table directly for
jobs to run, regardless of job run status. This was done to improve DB
performance as the view (which queried all "job_run" rows) was causing
significant DB contention.
Additionally, the option to limit job runs is now removed since it was
already hardcoded to -1 and not user-configurable anyways.
Should the need arise to implement this limit again, this will have to
be done in a different way since the new query does not account for
running jobs and limiting the rows returned after jobs are already
running would yield a no-op (the new query inserts nothing into
"job_run" if any given job is already running).
Before this change, upon the completion of a job run, the scheduler
would update a job_run entry with the completed status as well as the
number of objects affected by the run. Additionally, we then had a
cleaner job whose scope was deleting these completed entries from
job_run.
This commit changes this design to drop the cleaner job the and rolls
its functionality directly into the scheduler. Now, when any given job
run is complete, the scheduler will automatically delete it from the
job_run table itself.
In addition, the completed status has been removed as a valid status as
it is not set anymore.
This change follows a decision that given the data in these job_run
entries is already being deleted by the cleaner job, updating its state
when a job completes just to have it deleted is not efficient.
Additionally, no use-case for this data was surfaced.
* docs/client-agent: clarify use of override_upstream_dns_servers
The override_upstream_dns_servers option is recommended whenever
a user needs to override the DNS servers discovered from the system.
However, if a user supplies a DNS server that is only useable while
connected to a specific network, it will break the internet in
cases where it is not able to resolve these DNS servers.
Encourage users to supply both the VPN servers and the default
DNS servers.
* Update website/content/docs/api-clients/client-agent.mdx
Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com>
* Update website/content/docs/api-clients/client-agent.mdx
Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com>
---------
Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com>
* docs/client-agent: clarify configuration reload on MacOS
The previous configuration was known to confuse at least one reader.
It's easy to just copy the first command you see and run it, so
make that the non-destructive reload command.
* docs/client-agent: correct log level config example
* Update website/content/docs/api-clients/client-agent.mdx
Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com>
---------
Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com>
Michael Li
David Kanney
Mohit KumarandDan Heath
Damian Debkowski
Ryan Derr
Bharath Gajjala
Louis Ruch
Elim Tsiagbey
Michael Gaffney
Deniz Onur Duzgunandmickael e
Hugo
daniandDamian Debkowski