Kai Davenport

the heartbeat could contain info about "here is the capacity that I offer the network" - then we can: * know how many nodes there are * know how many...

Here is some output from a local devstack - it clearly shows a job that has concurrency=1 being accepted on 2 nodes... First place to look would be the requestor...

am braindumping here whilst it's in my mind - am currently plugging in "resource limits" so a compute node will not run jobs as fast as it sees them there...

Possibly what we should do is replace the JSONRpc api with a standard REST api because: * it is what ipfs uses * it would make plugging in otel handlers...

> is this with devstack? does the local ipfs client need to be educated about devstackiness? this is an excellent point thank you!

`Executed` makes sense for "I have finished running the compute job" but really that is `Verifying` because as soon as the shard has finished running - it's technicaly in "I...

there is a template for doing this that lives in the [compute node tests](https://github.com/filecoin-project/bacalhau/blob/741062b38d6b278e2b843bb7a441f1ccbbc75b3c/pkg/test/computenode/utils.go#L79)

You can see this state on [this branch](https://github.com/filecoin-project/bacalhau/tree/ipfs-devstack-nodes-syncing-cids) ```bash git fetch git checkout ipfs-devstack-nodes-syncing-cids export LOG_LEVEL=info cd pkg/test/devstack go test -v -count 1 -run ^TestSelectAllJobs$ . ```

So I propose that to get started - we implement the most explicit version of the CLI arguments as the baseline... i.e. this style: ```bash bacalhau run \ --concurrency 3...

Ahhh so I see this code: ``` model.JobEventBidAccepted: {Message: "Node accepted the job", IsTerminal: false}, // Job is on ComputeNode model.JobEventRunning: {Message: "Node started running the job", IsTerminal: false}, ```...