| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
As querying it is slow.
|
| |
|
|
| |
As I've found this useful in spotting systems which have problems.
|
| |
|
|
| |
Since this doesn't need to be persisted and changes often.
|
| |
|
|
| |
This is useful when interpreting the load information.
|
| |
|
|
|
|
|
| |
Previously, updating the status was used by the agent just to get back the
list of builds it was already allocated.
Now the status sent is actually stored, along with the 1min load average.
|
| |
|
|
|
|
| |
Rather than trying to count all builds and build results at startup. This
should speed up the coordinator starting up, as currently it gets slower the
more builds and build results are in the database.
|
| |
|
|
|
|
|
| |
I believe this will be useful when linking builds to other services, like the
Guix Data Service, since this information might be useful when joining up the
derivation being built to other derivations through the details of the outputs
produced.
|
| |
|
|
| |
A couple of the queries were wrong, this fixes it.
|
| |
|
|
| |
This should speed up fetching builds.
|
| |
|
|
| |
To allow making agents inactive to stop allocating builds to them.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, the allocator worked out the derived priorities for each
build. Unfortunately this is quite a complex query, and took lots of time. As
a result of this, I think the WAL could grow excessively while this long query
was running.
To try and mitigate this, add a new table to keep track of the derived
priorities for unprocessed builds. This requires some maintenance to keep up
to date, which in turn will make things like submitting builds slower, but I
think this might help keep transaction length and WAL size down overall.
|
| |
|
|
|
| |
It was completely broken, since it would just delete all entries from the
unbuilt outputs table.
|
| | |
|
| | |
|
| |
|
|
| |
It was broken in a previous migration.
|
| | |
|
| | |
|
| |
|
|
|
| |
Using natural IDs was nice at the start, but just doesn't scale. This
migration cuts the database size, and potentially speeds up queries as well.
|
| |
|
|
|
|
| |
This avoids the need to create agents upfront, which could be useful when
creating many childhurd VMs or using scheduling tools to dynamically run
agents.
|
| |
|
|
|
| |
This will allow doing things like restricting builds by matching up there tags
to the tags of the agents.
|
| |
|
|
|
|
|
|
|
| |
This isn't intended as some time based scheduling, but more as a way to slow
down builds by deferring processing them until some point in the future.
I'm intending to use this to test fixed output derivations. I can look up all
the derivations I want to test, then defer the builds to run spread out across
some period. This feature saves having to submit the builds gradually.
|
| |
|
|
| |
This makes fetching the tags for a build faster.
|
| | |
|
| |
|
|
|
|
|
| |
One of the slow things in the derivation ordered allocator is working out what
outputs are unbuilt, as this requires looking at all the derivation
outputs (of which there are lots), and checking if any build exists which has
succeeded.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As this information will come in useful when working out how to handle builds
for fixed output derivations. Specifically, I want to make it configurable
whether to add builds for fixed output derivations if a build already exists
for the output, but the derivation is different.
Currently, different fixed output derivations can be ignored but it's not
possible to just avoid adding more builds for non fixed output derivations
while adding builds when fixed output derivations change. This new information
will help enable that.
|
| |
|
|
|
| |
This can then be used by allocators to avoid allocating builds to agents that
they're never going to fetch.
|
| | |
|
| |
|
|
|
|
|
| |
This isn't particularly accurate, what's actually being stored is the current
time when the record is inserted in to the coordinator database, but that
should happen just before the agent starts the build, so hopefully that's good
enough.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
It worked under some database conditions, but was very slow under others. Move
more of the logic in to SQL in an attempt to make the allocator faster. This
sort of works, but there were some advantages to the approach before the
approach being replaced in this commit.
|
| |
|
|
| |
To use with the derivation ordered allocator.
|
| | |
|
| | |
|
| |
|
|
|
| |
This is important to speed up looking for derivations that provide an output,
that's used in the allocation process.
|
| |
|
|
|
|
| |
This will hopefully make it easier to create narinfo files for the outputs. I
think all of this information can be derived from the nar, but I'm not sure
how to do that, so maybe this can eventually be removed.
|
| |
|
|
|
|
|
| |
This is when a build was allocated to an agent, but the agent couldn't setup
the environment for the build. One failure I'm particularly thinking about is
where inputs to the derivation are missing, so add another table to store
them.
|
| | |
|
| |
|
|
|
|
|
| |
One table to store which build is allocated to which agent, and another to
store a "plan" of allocations. For this plan, a build can be potentially
allocated to multiple agents, and which agent it will be allocated to depends
on which agent claims it first.
|
| | |
|
| | |
|
| | |
|
| |
|