1 of 14

Job Orchestration Logic / sequence update

�Technical discussion; September 12, 2024�kabir@nunet.io

A Global Economy of Decentralized Computing

2 of 14

Congrats re: `dms0.5-boot` feature freeze and release process start

3 of 14

General notes

Basics for the orchestration is NuActor system (see previous tech discussion);
Messages / behaviors / capabilities – primitives on which we will build orchestration logic, which will evolve with the platform versions;
All calls in the sequences are Actor messages (with proper capabilities, etc.);
NuActor behaviors == alphabet; Basic orchestration principles == grammar rules; Job orchestration == language;
Alphabet is finite and simple; grammar is [somewhat] well defined; language allows to produce infinite expressions/logic…

4 of 14

Job Orchestration logic update : current description

Based on the image of small subnetwork:

Direct user: has local access to its dms via cli / rest-api;
DMS1 (service provider): ‘owned’ by the direct user;
DMS2 : independent compute provider 1;
DMS3 : independent compute provider 2;
DMS4 : independent compute provider 3;

Disclaimer: this is general description and details could be missing / some things incorrect;
Link to the full job-orchestration sequence diagram;
Goals:

detail each separate component;
gradually develop and build / test them during release process;
release full orchestration process with final `dms0.5` in Dec 2024;
following this description we can (and will) formulate an end-to-end test;

5 of 14

List of orchestration steps

Job post
Converting Job Post to Bid Request(s);
Routing Plan;
Search and matching (for proper resources):

Broadcast Bid Requests (on behalf of Service Provider);
All reached compute providers estimate bid requests and send bids;

Generate deployment plan;
Deployment plan execution;

Contract closure for each job;
Invocation and allocation for each job;
Execution monitoring / orchestration;
Contract settlement;

[Sending results to the user]

6 of 14

Job Posting

sequence diagram section;
Notes / comments:

NuNet Job / workflow description / type needs to be finished;
Conversion from ‘conventional’ formats (like kubernetes / nomad, etc.) needs to be finished;
Job processing happens in new Allocation for which proposed functionalities:

‘native executor’ as go worker;
allocations can create new allocations (via Actor interface);
parent-child relationships between allocations follow the structure of ‘deep/nested/recursive’ workflow description!

7 of 14

Converting to BidRequests

sequence diagram section;

8 of 14

Routing plan

For now, a routing plan is just a sequence for finding correct topics to publish BidRequests;
sequence diagram section;
Notes / comments;

Open ended computing joins two components: Actor Model and Graph Computing (see yellow-paper);
Eventually routing will use graph computing concepts;
in graph computing terms: routing is expressed as graph traversals;
We decided not to implement graph computing package in dms0.5, therefore will work around that;
which means that we do graph traversals via gossipsub / topic-limited broadcast;
mathematically it is the same process – will be integrated into search and matching when graph computing is implemented;

9 of 14

Search and Matching

Main part of the job orchestration and NuNet tech offering!;
Many ways to describe formally in terms of: decentralized constraint satisfaction; decentralized search and matching, ‘offer-networks’ solver, AI-DSL implementation, etc.
S ection of sequence diagram;
Loops:

publish BidRequests to the network (i.e. traverse the graph);
collect Bids from interested / capable compute providers (HardwareCapability / Comparison logic);
Collect all the bids into single data structure that can be reasoned upon for further steps;
Note, that search and matching loop (from T/Ch perspective) cannot be proven to be computable in advance; the only way to see if it is computable is to ‘run and see what happens’; Full open-ended computing implementation will attack this problem; for now, we will use thresholds for the process to terminate and return intermittent state/results;

10 of 14

Generate deployment plan

In the past we were calling this step ‘select best bid’, but deployment plan is broader;
Since we are deploying / orchestrating a compute workflow consisting of two parts that will run on two different machines which will have to communicate with each other, topological distance between potential machines should be considered when ‘selecting best bids’;
Essentially, we have to solve another combinatorial / constraint satisfaction problem here:

figure out which compute providers provide best hardware / price/ speed combination to run individual jobs in the workflow;
however, consider also the network topology between these machines in the final decision to deploy;

Similarly to step Routing plan, eventually this should be solved by full-fledged graph computing; but for now we use separate loop;
Section of sequence diagram

11 of 14

Job completion

Section of sequence diagram
Wrapping up all actors and sending the response back to the user;
Notes / Comments:

This aspect / loop includes the interaction between platform side of NuNet and use-case side of NuNet (so the boundary of NuActor system);
‘User’ participant in the diagrams is the ultimate user of the use-case / business model;
‘DMS1 - Service provider’ is the component though which developers / partners / application providers will provide end-user applications to the public;

12 of 14

Summary and further steps (or vise versa);

Formalize the `dms0.5` feature scope gradually moving from `dms0.5-boot` to `dms0.5` collaboratively working on feature scope freeze and feature tests in test-suite;
Some important aspects to consider (non-exhaustive):

NuNet Job / workflow description / type needs to be finished;
‘native executor’ as go worker;
parent-child relationships between allocations that follow the structure of ‘deep/nested/recursive’ workflow description!
supervisor logic and parent-child relations needs to be finished for that;
for routing plan: topic semantics and data structure;
for search and matching: sort and constraint preferences (price/time?);
integrate tokenomics / contract logic into NuActor system / UCANs;
job verification logic and workarounds (looking for integrating third party frameworks / solutions);

13 of 14

NuActor superpowers

Behaviors is our alphabet, which is small and limited, but can evolve;
NuActor system contains the explicit grammar definition (i.e. how letters and words can be combined in well-formed sentences);
Job orchestration logic is text which can express anything computational and beyond – and form the open ended computing universe;