| 22 Jun 2021 |
 tomberek | The granularity (or lack of) of some builds is the primary limitation for partial rebuilds. I’ve thought of a check-pointing mechanism for certain builds would be helpful, but I don’t know how to make it general enough. I’m also under the impression some PoCs have been done with bazel and a few others. | 20:38:25 |
 David Arnold | Thanks! I think flakes with their very strict input / output interfaces can be a milestone towards granularity. What do you think? | 20:42:58 |
| David Arnold | Also I'm breading over this addition:
## `taskcluster`? (pha, `nix` build DAG!)
Let's circle back to `taskcluster` as mentioned in the introductory rant. It seems that task cluster knows how to run a DAG of batch jobs. That's a bit of a different focus than a proper state machine, though. As for the build itself, we have our beloved `nix` primitives to resolve the build DAG.
| 20:43:32 |
| David Arnold | I'm not familiar enough with how everything is currently working, but would it make sense to wish for
some remote build delegation and parallelization while observing the inherent build DAG.
| 20:44:43 |
| David Arnold | (like builtin into nix itself, if that's not already the case?) | 20:44:59 |
 Rick (Mindavi) | Content-addressability will ensure that partial rebuilds will work (when it's determined that there's no influence on the build) | 20:47:27 |
| Rick (Mindavi) | Nix will indeed build in parallel when it's possible | 20:47:43 |
| Rick (Mindavi) | Taking the graph into account | 20:47:56 |
| David Arnold | Cool! | 20:48:05 |
| David Arnold |
nix already knows how to parrallelize when possible.
| 20:48:26 |
| David Arnold | Feel free to add / or reword to make it more concise: https://demo.hedgedoc.org/sfTFtgceQJqI2gPqIwXQ5Q#taskcluster-pha-nix-build-DAG | 20:49:48 |
| David Arnold | The point to bring about is: nix is task cluster in the build domain, and everything else is better handled by a proper state machine, not a simple DAG. | 20:50:29 |
| tomberek | I’m not understanding where you intend state would be kept. Or where this state machine would run. (I’ve found it possible, I’m just not grokking specifically what you intend.) | 21:41:19 |
| David Arnold | I am a bit bisased, since I have somewhat knowledge of how zeebe works: it's a state machine that otherwise does event sourcing into a data lake. +- | 22:04:10 |
| David Arnold | It's messages all the way down, and they modify constitute the state. | 22:05:07 |
| tomberek | I pulled a trick recently where I put state into Git (it was very slow moving state, human time-scales) and Hydra would pick it up and run a DAG of the changed transformations. Along with an auto-scaling group for builders, it made a data ingestion system with many nice qualities inherited from Nix. | 22:24:45 |
| David Arnold | Iirc the state in zeebe is distributed among the brokers without central db for running workflow instances, once terminated they (or alternatively all events during execution) are persisted into the data lake. | 22:26:58 |
| David Arnold | Brokers may have a local in-mempry db or something. | 22:27:17 |
| tomberek | So events are considered independent? | 22:28:11 |
| David Arnold | But it's basically pure event sourcing between brokers, which is a handy byproduct of the message queue used (don't know which) | 22:28:19 |
| David Arnold | No, I guess events are considered unique (at most once, at least once semantics) | 22:29:00 |
| David Arnold | Not sure though. | 22:29:09 |
| David Arnold | Zeebe:
- apiserver + broker
- message queue
- elasticsearch (datalake)
| 22:30:23 |
| David Arnold | That's about it. | 22:30:34 |
| David Arnold | Ok the broker has fancy features such as distributed runtime state and the workflow engine 😀 | 22:31:08 |
| David Arnold | Each bpmn action has roughly/conceptually two events/messages:
JobStart + JobFinish | 22:33:29 |
| David Arnold | And workers need to understand those and return meaningful output (JobFinish message) | 22:34:11 |
| David Arnold | It's actually pretty simple. | 22:36:05 |
| David Arnold | The biggest challange is packaging zeebe / OPA for nixpkgs. | 22:36:33 |
| 23 Jun 2021 |
 Taneb | How do the "Previous Hydra evaluation" and "Previous Hydra buld" input types work? | 15:21:59 |
