Development RoadMap for ChimeraPy-Dashboard/ API Planning

[umesh-timalsina]

Development RoadMap for ChimeraPy-Dashboard/ API Planning

This is a rough road map for developing dashboard for ChimeraPy. Eventually, this will be formalized but this is a quick
and dirty version (per se).

Currently, the challenge is how to think about different nodes and their components. So, a nice roadmap with API Schema
and corresponding typescript components should be made possible. There are several possibilities, however, the straight
forward way to do it is to gather the network tree at once is a svelte store and eventual changes in the tree should be
populated by a message passing interface from the server.

But, what does the data look like. And what are the routes?

This is an ongoing/evolving thought process. However, Lets look at the entities in our Network. Note that the graph is a
separate entity and should be treated as such. i.e. A manager will have access to all the global nodes that can be used
to create a pipeline.

[umesh-timalsina]

Manager

States

A manager can be in the following states (we can name them accordingly):

1. Started (waiting for workers to connected) / The dashboard will only start after this.
2. All the workers are connected.
3. Executing a pipeline
4. Stopped and finalizing bookkeeping

Properties

enum ManagerState {
    STARTED = 0,  // Just Launched
    WORKERS_CONNECTED = 1, // Few Workers are connected
    NODES_READY = 2, // Nodes are ready (Graph Commited)
    EXECUTING = 3,  // Executing the current pipeline
    STOPPED = 4, // Stop Command has been applied
    FINALIZING = 5, // Finalizing the bookkeeping and datatransfoer

}

interface Manager {
    state: ManagerState;
    ip: string; // Define proper IP
    port: number;
    workers: Worker[]; // ToDo Worker Definitions
    graph?: Graph; // ToDo Graph Definitions
    worker_graph_map?: { string: string }[];
}

Capabilities

1. Boot a worker (and nodes)

More thought is needed here?

[edavalosanaya]

This is a good start for the Manager :). A stage to add to the bullet list between steps 2 and 3 is the committing of the DAG graph (i.e. after the workers are connected, the DAG, its mapping, and setup need to be orchestrated by the Manager) Since this step can take a while (plus waiting for researchers to perform manual actions and troubleshooting possible errors), I think it's worth considering as an independent stage before the pipeline execution.

[umesh-timalsina]

Worker

A worker will have similar properties (is a peer in the distributed network) and can data is only accessible from the
manager.

Currently, I have thought the following properties for a worker:

interface Worker {
    ip: string;
    name: string;
    id: string;
    port: number;
    nodes: Node[];  // ToDo NodeDefinition
}

[edavalosanaya]

I think this is good. We will need to add id to the backend as well.

[umesh-timalsina]

A node is an actual process entity running in the worker. It can be a source / sink node producing/ consuming data but
also might be running heavy computational jobs.

Properties

interface Node {
    name: string;
    id: string;
    port: number;
    running: boolean;
    data_type: 'Video' | 'Series' | 'Audio';
    dashboard_component: null | string;
    capabilities: ('callibrate'| 'start' | 'stop')[];
}

[edavalosanaya]

Good interface. The one attribute that I am not sure about or at least haven't wrapped my head around that is worth further discussion is the data_type. That is because Node can generate multiple data streams (e.g. the eye-tracking Tobii Glasses 3 generates video, audio, gaze, and event logs).

Some original thoughts for this are that we could leverage the DataChunk that is being published by the Nodes. The nodes can store the multiple data streams and tag them with their data type ('image', 'audio', 'series', etc), and this could be an easy way for developers to specify what type of Dashboard component they would like. Maybe not the best approach, but in the front end, once you received the data chunk, you can determine the components needed.

[edavalosanaya]

On Second thought. This is where the most careful planning needs to be done. For example, calibrating a node might mean different things, slider-based inputs/value-based inputs in the POST data. Modes etc... I would like to do less hard coding as possible.

That is a good point, we need to consider that capabilities might not be simple buttons but might need to have inputs (sliders, text, or drop-down menus) as well. For example, a Camera-Video Node might need the capability of specifying which camera by id.

[umesh-timalsina]

While the DataChunk approach might work on the python side of things, for example displaying in a window manager, things get quite tricky when it comes to displaying it in the browser. This is what I am not sure about as well and further research is necessary. For example, what is the best way to stream arrays so that they can be displayed as images in the browser? The same goes for any other time series data.

[edavalosanaya]

Very good points, will do some research on handling data in JS/TS and visualizing it.

[umesh-timalsina]

The other thing to consider is calibration without feedback doesn't make sense, because so much of it is dependent on the environment. So, when the sensor is being calibrated it has to publish data IMO.

[umesh-timalsina]

Additionally, the dashboard code development has been haphazard. It might be nice to build an acceptable version and work on one feature at a time. I am thinking that we might just do the following:

1. Clear Definition of the API of these endpoints (Backend)

• GET /network - A json returning an object adhering to an extensible schema definition for the network

2. Ability to server static files from the python code.
3. Display Network Status via stores
4. Tests with Mocks (Random Mutation capabilities would be great).

[umesh-timalsina]

For the static files, we can for now do the monolith repo or if you would like, we can create a separate repo.

I have disabled SSR and used adapter-static for svelte-kit. This should work fine for our use case. This would add a workflow when publishing to pypi.

I was thinking we start with a very simple GET /network. This would give me a json of the entire network.

[umesh-timalsina]

Take it with a grain of salt, but the mock data I am using looks like the following

[edavalosanaya]

Sounds good. I can make GET /network working soon. For the response, would a list of Workers, with the attributes you specified in the interface above, would work for you?

[umesh-timalsina]

But for now, its not necessary to extend the current object model to support this. I would just add the following functions to Node/ Manager and Worker and iterate over them in the manager to return this a json.

def dashboard_dict(self) -> Dict[str, Jsonable]:
   ...

[edavalosanaya]

Take it with a grain of salt, but the mock data I am using looks like the following

Okay working on it now, tracked by #88.

[umesh-timalsina]

This has stalled a bit but here's a JSON schema that we can start out with.

{
  "$schema": "http://json-schema.org/draft/2020-12/schema",
  "$id": "network.schema.json",
  "title": "network",
  "description": "network details for chimerapy",
  "type": "object",
  "properties": {
    "id": {
      "description": "manager id",
      "type": "string"
    },
    "name": {
      "description": "manager name",
      "type": "string"
    },
    "ip": {
      "description": "manager ip",
      "type": "string"
    },
    "port": {
      "description": "manager port",
      "type": "integer"
    },
    "platform": {
      "description": "manager platform information",
      "type": "object",
      "properties": {
        "name": {
          "description": "platform name",
          "type": "string"
        },
        "operating_system": {
          "description": "operating system",
          "type": "string"
        },
        "architecture": {
          "description": "architecture",
          "type": "string"
        },
        "python_version": {
          "description": "python version",
          "type": "string"
        },
        "ram": {
          "description": "ram",
          "type": "string"
        }
      }
    },
    "routes": {
    "description": "routes for the manager",
    "items": {
      "$ref": "#/$defs/route"
    }
  },
    "publishing_logs": {
        "description": "publishing logs",
        "type": "boolean"
    },
    "logs_subscription_port": {
        "description": "logs subscription port",
        "type": "integer"
    },
    "workers": {
    "description": "workers connected to the manager",
    "type": "array",
    "items": {
      "type": "object",
      "properties": {
        "id": {
          "description": "worker id",
          "type": "string"
        },
        "name": {
          "description": "worker name",
          "type": "string"
        },
        "ip": {
          "description": "worker ip",
          "type": "string"
        },
        "port": {
          "description": "worker port",
          "type": "integer"
        },
        "nodes": {
          "type": "array",
          "items": {
            "type": "object",
            "properties": {
              "id": {
                "description": "node id",
                "type": "string"
              },
              "name": {
                "description": "node name",
                "type": "string"
              },
              "ip": {
                "description": "node ip",
                "type": "string"
              },
              "port": {
                "description": "node port",
                "type": "integer"
              }
            },
            "required": [
              "id",
              "name",
              "ip",
              "port"
            ]
          }
        }
      },
      "required": [
        "id",
        "name",
        "ip",
        "port",
        "publishing_logs"
      ]
    }
  },
    "required": [
      "id",
      "name",
      "ip",
      "port",
      "routes",
      "workers"
    ]
  },
  "$defs": {
    "route": {
      "type": "object",
      "properties": {
        "url": {
          "description": "url for the route",
          "type": "string"
        },
        "method": {
          "description": "method for the route",
          "$ref": "#/$defs/method"
        },
        "body": {
          "description": "body for the route",
          "type": "object"
        },
        "description": {
          "description": "description for the route",
          "type": "string"
        }
      },
      "required": [
        "url",
        "method",
        "description"
      ]
    },
    "method": {
      "type": "string",
      "enum": [
        "GET",
        "POST",
        "PUT",
        "DELETE"
      ]
    }
  }
}