Commit message (Collapse) | Author | Age | |
---|---|---|---|
* | Fix up a load of the tag related code | Christopher Baines | 2021-01-17 |
| | | | | | Turns out vector-fold and vector-map don't work like I'd expected them to, like fold and map for vectors. | ||
* | Sure up handling of exceptions within Guile (backtrace) | Christopher Baines | 2021-01-17 |
| | |||
* | Fix bug in allocators from alist to vector switch for tags | Christopher Baines | 2021-01-17 |
| | |||
* | Stop treating collections of tags as alists | Christopher Baines | 2021-01-17 |
| | | | | | | | This translates poorly to JSON, as you can't have multiple values for one name in a JSON object. Is also is risky in terms of assoc-ref being used, and not considering more than one key. Using a vector of pairs should help in both situations. | ||
* | Implement agent/build tag matching | Christopher Baines | 2021-01-17 |
| | | | | | | | | | If the agent and build tags have overlapping keys, compare the tag value, and only match the build to the agent if the value matches. There's a potential issue with some of the code here in that it doesn't cope well with tags with matching keys but differing values, but this is just a first implementation. | ||
* | Allow changing agent tags through the command line | Christopher Baines | 2021-01-17 |
| | |||
* | Add client code for changing agent tags | Christopher Baines | 2021-01-17 |
| | |||
* | Include agent tags in the details response | Christopher Baines | 2021-01-17 |
| | |||
* | Add tags for agents | Christopher Baines | 2021-01-17 |
| | | | | | This will allow doing things like restricting builds by matching up there tags to the tags of the agents. | ||
* | Exclude allocated builds from the basic allocator | Christopher Baines | 2021-01-17 |
| | |||
* | Expose allocated builds for each agent | Christopher Baines | 2021-01-17 |
| | |||
* | Add missing thunk | Christopher Baines | 2021-01-16 |
| | |||
* | Tweak datastore-list-unbuilt-derivation-outputs | Christopher Baines | 2021-01-16 |
| | | | | So it works with the code in handle-build-result. | ||
* | Tweak agent messaging error handling | Christopher Baines | 2021-01-16 |
| | |||
* | Don't error when builds don't have a created at time | Christopher Baines | 2021-01-16 |
| | |||
* | Allow agents to skip submitting build outputs | Christopher Baines | 2021-01-16 |
| | | | | | | | | | If the coordinator isn't going to use the outputs, because they've already been built for example, then save some time by not processing and submitting them. This will probably need to get more configurable on the coordinator side in the future. | ||
* | Start migrating derivation-inputs to derivation_inputs | Christopher Baines | 2021-01-16 |
| | | | | As I think underscores are more idiomatic in JSON. | ||
* | Tell agents when to submit built outputs | Christopher Baines | 2021-01-16 |
| | | | | This is often unnecessary if the outputs have already been built. | ||
* | Add datastore-list-unbuilt-derivation-outputs | Christopher Baines | 2021-01-16 |
| | |||
* | Allow nesting transactions in code | Christopher Baines | 2021-01-16 |
| | | | | | You can't actually nest transactions, so just track if one is in progress, and don't attempt to start a transaction if that's the case. | ||
* | Use a readonly transaction for datastore-fetch-build-to-allocate | Christopher Baines | 2021-01-16 |
| | | | | As it doesn't write to the database. | ||
* | Fix some sqlite datastore slot references | Christopher Baines | 2021-01-16 |
| | |||
* | Move the build result storing logic in to the coordinator module | Christopher Baines | 2021-01-16 |
| | | | | | And out of the datastore. This means that datastore code doesn't have too much logic in it. | ||
* | Move build allocation complexity out of the datastore | Christopher Baines | 2021-01-16 |
| | | | | | And in to the coordinator module. This will make adding more datastore's easier. | ||
* | Add local agent messaging | Christopher Baines | 2021-01-16 |
| | | | | | This is untested, but might be quite cool for running a single agent instance of the build coordinator, all in one process. | ||
* | Move triggering allocations out of the http server | Christopher Baines | 2021-01-15 |
| | | | | As this code should be in the coordinator. | ||
* | Rework the agent messaging modules | Christopher Baines | 2021-01-15 |
| | |||
* | Use methods for the agent messaging | Christopher Baines | 2021-01-15 |
| | | | | This will allow adding more agent messaging approaches. | ||
* | Tweak agent queue timings | Christopher Baines | 2021-01-12 |
| | | | | | Wait slightly longer between starting new threads, and give more time for new jobs to arrive for running threads. | ||
* | Work on the agent thread handling some more | Christopher Baines | 2021-01-06 |
| | | | | | Various changes, hopefully improvements. Inactive threads should stop promptly, and new threads should start promptly when new builds arrive. | ||
* | Give more time for substitute downloads | Christopher Baines | 2021-01-03 |
| | | | | | By the agent. Turns out 10 minutes isn't long enough for some large and slow downloads. | ||
* | Fix the stdin based status display when running under the shepherd | Christopher Baines | 2021-01-03 |
| | | | | | The current input port is #<input: file 0>, which gives eof when read from, so detect this and stop trying to read from it. | ||
* | Add debugging code for the agent status output | Christopher Baines | 2021-01-03 |
| | | | | As this doesn't seem to be working properly when running under the shepherd. | ||
* | Enable matching tags by just the key | Christopher Baines | 2021-01-03 |
| | |||
* | Have build list cope with multiple pages | Christopher Baines | 2021-01-03 |
| | |||
* | Ensure the agent fetches builds if it doesn't have any | Christopher Baines | 2021-01-02 |
| | |||
* | Make sure to have the agent try fetching builds | Christopher Baines | 2021-01-02 |
| | | | | Even if there are no worker threads running. | ||
* | Stop agent threads if there's no work within some time period | Christopher Baines | 2021-01-02 |
| | | | | So that the number of threads can decrease without new jobs arriving. | ||
* | Don't start new agent threads if there are no jobs | Christopher Baines | 2021-01-02 |
| | |||
* | Only use lookup-narinfos on one thread at a time | Christopher Baines | 2021-01-02 |
| | | | | In the agent, as I doubt the new connection caching in Guix is thread safe. | ||
* | Tune agent retrying | Christopher Baines | 2021-01-01 |
| | | | | So that the agent spends less time waiting. | ||
* | Work around caching broken connections in Guix | Christopher Baines | 2021-01-01 |
| | | | | Introduced in be5a75ebb5988b87b2392e2113f6590f353dd6cd. | ||
* | Add missing suffix to an agent log line | Christopher Baines | 2020-12-31 |
| | |||
* | Add more information to the agent info output | Christopher Baines | 2020-12-31 |
| | |||
* | Display useful information about agent state | Christopher Baines | 2020-12-31 |
| | | | | When the agent receives input or SIGUSR1. | ||
* | Have the agent fetch builds based on the current number of threads | Christopher Baines | 2020-12-31 |
| | | | | | | This means that if the agent is only processing 2 builds at a time, it'll only fetch up to two builds, rather than whatever maximum it would fetch. This avoids fetching builds unnecessarily. | ||
* | Rate limit the agent starting threads to process builds | Christopher Baines | 2020-12-31 |
| | | | | | | | | | | Allow rate limiting new worker threads starting in the agent. Currently if the running jobs is limited by system load, lots of jobs start, the load goes up, then the jobs gradually finish, and once the load decreases, lots of jobs start again, and the cycle repeats. Rate limiting the starting of new threads might help to soften the jobs all starting at once. | ||
* | Avoid fetching builds when they won't start immediately | Christopher Baines | 2020-12-30 |
| | |||
* | Only run one build when the load is high | Christopher Baines | 2020-12-30 |
| | | | | | This should avoid behaviour that I've observed where sometimes no builds are running, because the load is high. | ||
* | Alter the work queue to allow for a dynamic thread count | Christopher Baines | 2020-12-30 |
| | | | | | | This means that rather than having threads, just sleep, the number of threads running can change. One good effect of this is that a bounds can be easily put on the number of threads (like a lower bound). |