This change invalidates tokens based on more parameters. Tokens that were
generated for previous attempts of spinning up an instance will be invalidates.
Also, only instances that are in Running or Creating will be able to authenticate.
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
This change increases the tools refresh interval to 5 minutes, cleans
up the websocket code a bit, augments the error message that may be returned
when trying to delete a runner in an invalid state and removes a log message
that does not add much value.
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
I accidentally disabled the log streamer when I moved the config options
to their own section. This change fixes that.
This change also adds some safety checks and locking when cleaning up stale
clients. The websocket hub Write() function now copies the message before
sending it on the channel to the clients.
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
Pool managers will have 2 fields identifying which manager generated
the log line.
In the future, we will add tracking ids in various cases, allowing
us to track down issues faster.
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
This change switches GARM to the new structured logging standard
library. This will allow us to set log levels and reduce some of
the log spam.
Given that we introduced new knobs to tweak logging, the number of
config options for logging now warrants it's own section.
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
Allow runners to update their own system information. Runners can now send
back os_name, os_version and agent_id back as part of a POST to
CALLBACK_URL/system-info/.
The goal is to get better info in regard to the actual OS that's running
and to move the agent_id from the status updates to the system-info callback.
The status updates should be used only to send back info about the status of
the installation process.
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
Canonical have relicensed the LXD project to AGPLv3. This means that we can
no longer update the go LXD client without re-licensing GARM as AGPLv3. This
is not desirable or possible.
The existing code seems to be Apache 2.0 and all code that has already been
contributed seems to stay as Apache 2.0, but new contributions from Canonical
employees will be AGPLv3.
We cannot risc including AGPLv3 code now or in the future, so we will separate
the LXD provider into its own project which can be AGPLv3. GARM will simply
execute the external provider.
If the client code of LXD will ever be split from the main project and re-licensed
as Apache 2.0 or a compatible license, we will reconsider adding it back as a
native provider. Although in the long run, I believe external providers will
be the only option as they are easier to write, easier to maintain and safer to
ship (a bug in the provider does not crash GARM itself).
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
On large deployments with many jobs, we cannot check each job that
we recorded in the DB against the GH API.
Before this change, if a job was updated more than 10 minutes ago,
garm would check against the GH api if that job still existed. While
this approach allowed us to maintain a consistent view over which jobs
still exist and which are stale, it had the potential of spamming the
GH API, leading to rate limiting.
This change uses the scale-down loop as an indicator for job staleness.
If a job remains in queued state in our DB, but has dissapeared from GH
or was serviced by another runner and we never got the hook (garm was down
or GH had an issue - happened in the past), then garm will spin up a new
runner for it. If that runner or any other runner is scaled down, we check
if we have jobs in the queue that should have matched that runner. If we did,
there is a high chance that the job no longer exists in GH and we can remove
the job from the queue.
Of course, there is a chance that GH is having issues and the job is never
pushed to the runner, but we can't really account for everything. In this case
I'd rather avoid rate limiting ourselves.
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
This change adds a flag on providers that allows users to disable JIT
configuration even when it's available. For context, JIT is available
on github.com and any GHES instance >=3.10.
This option is a stopgap measure for providers that have not yet been
updated to use JIT configs instead of runner registration tokens.
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
as some provider binaries probably need additional environment variables
set (e.g kubernetes as client-go depends on KUBERNETES_SERVICE_ vars) it
should be possible to define a list of environment variables which
should get bypassed into the provider binary execution
