distributedtaskscheduling / jobadder

Source code of the JobAdder project

JobAdder

Source code of the JobAdder project

jobadder's Issues

Figure out a way to close the server/worker daemons gracefully

• Setup & Start server

• Add stop command to the command handler & verify it works

• Systemd integration (service file, with sql deps and graceful stop)

• Installation of the above (maybe a script?)

CLIHandler class diagrams

ServerConfig

Configuration for the server.
Contains things like a list of special resources (different licenses and how many of them are available), and some options for the scheduling algorithm.

Implementation of user config files

Message classes

Implementation of the Job class and related classes

Email Notifier and Web API

I think I was assigned these two in our last meeting.

Two questions:

1. Do we store a list of emails for each user, or do we store an email for each job?
2. Do we need HTTPS for the server or plain HTTP?

Notifier

This class sends emails when a job is completed.

WorkerProxy

The real proxy the Server uses for communication with the Worker.

Make all proxies abstract base classes

We'll most probably need to have dummies here for the unit tests, so the WorkerServerProxy, etc. need to be interfaces.

Dispatcher

Implementation of the dispatcher class.

WebAPI

Implementation of the Web server and all the associated requests.

User -> Server messages

Messages which the UserClient sends to the Server.
They operate on the ServerDatabase.

from ja.user.message:

• add

• cancel

• query

IWorkerServerProxy

A mock implementation for the Proxy which the Worker uses to communicate with the Server. This class can then be used to test that for ex. the DockerEvents class correctly communicates with the Server that a job has finished/crashed, etc.

Scheduler and database class diagrams

Mock database

This is a database which is used for unit tests - it doesn't need to connect to a real database, but should implement the ServerDatabase interface.

Config classes

Server Main Class

I don't think we have this anywhere.

Response classes should be unified

As discussed in the meting, I think we should have only a single Response class instead of Response, ServerResponse, and WorkerResponse.
Since we currently have a lot of PRs open this change should wait until we have a lower amount of PRs open.

Default scheduling algorithm

Uses #78

Infrastructure for integration phase

Class which starts all 3 components.

Worker -> Server messages

Messages which the worker sends to the server. They operate on the Database.

• crashed

• done

• register

• retire

User Server Proxy

The real proxy which is used by the user to communicate to the server.

Dispatcher

Handle SSH connection timeout in WorkerProxy

If the connection to a work machine suddenly drops, we should eventually get a timeout on the SSH connection (or we may want to periodically send pings). Anyway, when this happens, it would make sense to mark the machine as offline and probably mark the jobs on it as CRASHED.

Would be nice to have.

Multiple users/workers on the same machine test

IWorkerProxy

A mock implementation for the proxy that the Server uses to communicate to Workers.

Setup up unit tests in our CI

WorkerServerProxy

The proxy which represents the Server on the Worker.
Related to #61

Default scheduling policies

These are used by the default algorithm to distribute jobs among work machines.

Scheduler

Implementation of the Scheduler class.
Needs #79 and #59

Server -> Worker Messages

Messages which the Server sends to the server.

Basically all the classes in ja.common.message.worker_commands:

• cancel_job

• get_workload

• pause_job

• set_filters

• start_job

Docker classes and Worker classes

Decide on coding style and add CI

We really should have a consistent style. My proposal is to use the official Python styleguide: PEP 8.There are also good tools which check this, for example flake8.

Another thing is checking the type hints consistency with MyPy.

Anything else we want to check?

Worker config

Worker configuration classes, it should be able to read for ex. the IP address of the server.

Server Main

The main class for the Server.
Should start all components and run the main loop.

Add hidden connections so that the class diagram looks better

Currently, its layout is suboptimal.

Support for logging

It should support multiple verbosity levels.

common is importing from server

I added an argument of type ja.common.database.database.ServerDatabase to the execute method of ja.common.message.server.ServerCommand.
As a consequence common is now importing from server.
We had agreed that user, server, and worker should only import from common.
Should we allow that common also (rarely) imports from user, server, or worker?
Otherwise we would have to move the entire database into common.

SSHConnection implementation (+Mock)

Class which does the actual message transmission and calls the Remote on the remote machine.

IServerProxy

The proxy which the user client uses to communicate with the server.
This is just about a mock implementation, which doesn't really send the commands over the network, but is used only in unit tests.

Augment proxies to set type_name

I just noticed we never set the type_name which the command handlers use to differentiate between commands:

https://github.com/DistributedTaskScheduling/JobAdder/blob/master/src/ja/common/proxy/command_handler.py#L60

As a result, the server and the worker will never be able to parse commands (except if I am mistaken and this is set somewhere, but I could not find any reference to type_name aside from the command handlers). I think we can either

1. Make the proxies pass it as an additional argument to the SSH connection

2. Make the SSH connection infer the type by looking at the Python class name (object.__class__.__name__)

What do you think is the better approach? My personal preference is 2. since it is easier to implement and won't require changing the interfaces, plus removes the need to manually specify the type everywhere.

SQL Database

The real implementation of the database class which will be used in production.

Remote

Implementation of the Remote program. Not sure how to unit test this properly, but probably we can extract the Job owner verification and unit test that.

CLI Handler

The handling of command line arguments by the user client.

Implementation of ja.server.database.types classes

Proxy classes

IProxyFactory

A mock implementation for the ProxyFactory, which returns mock WorkerProxies

Implement Serializable base class functions

WorkerMain

The main class for the worker, using a mock server proxy from #64

Should also listen on the local socket for new commands from the server (that part could probably be shared with the server, should be investigated)