| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|