vln37/taskmaster

A supervisor-like program

classDiagram
direction LR
namespace common {
    class Server {
        -UnixListener socket
        -Vec~epoll_event~ events
        -RawFd pollfd
        HashMap~Key, UnixStream~ clients

        -listen()
        +accept()
        +recv()
        +send()

    }
    class Request {
        +Cmd command
        +Vec~string~ arguments
        +Key client_key
        +validate()
    }
    class Response {
        +String message
        +finished bool
        +as_bytes()
    }
    class Cmd {
        <<Enumeration>>
        ATTACH
        UNATTACH
        LOG
        HEAD
        STATUS
    }
    class CmdHandler {
        <<Interface>>
        handle(request)
        attach(request)
        unattach(request)
        log(request)
        head(request)
        status(request)
        other(request)
    }
    class ClientState {
        <<Enumeration>>
        Attached
        Unattached
    }
}

%% Request "*" --* "1" BackEndClient
%% Server "1" --o "1" TaskMaster
%% Server "1" --o "1" Client
%% CmdHandler ..|> BackEnd


namespace daemon {
    class TaskMaster {
        -Server server
        -BackEnd backend
        -HashMap~Key, BackEndClient~ clients
        -Status status

        +build(config)
        +reload()
        +accept()
        +receive(Key)
        +respond(Key)
    }

    class Status {
        <<Enumeration>>
        Starting
        Reloading
        Active
    }

    class BackEndClient {
        +ClientState state
        +VecDeque~Request~ requests
    }

    class BackEnd {
        +TaskMasterConfig config
        +HashMap~String, Program~ programs
        +startProcesses()
        +updateProcesses()
        +processRequest() Response
    }

    class Program {
        +ProgramConfig config
        +Vec~Process~ processes

        +build()
        +update()
    }

    class Process {
        +Result~Child, Error~ child
        +ProcessStatus status
    }

    class ProcessStatus {
        <<Enumeration>>
        Starting,
        FailedToStart,
        Active,
        GracefulExit~u32~,
        Killed~Signal~,
        FailedExit~u32~,
    }

    class TaskMasterConfig {
        <<yaml representation>>
        +HashMap~String, ProgramConfig~
    }
}

Status --o TaskMaster
BackEnd "1" --* "1" TaskMaster
BackEndClient "*" --* "1" TaskMaster
Program "*" --o "1" BackEnd
Process "1" --o "1" ProcessStatus
Process "*" --o "1" Program
TaskMasterConfig "1" --o "1" BackEnd


namespace ctl {
    class Client {
        -Server server
        -VecDeque~string~ queries
        -ClientState state
    }
}

namespace log {
    class Logging {
        <<Macros>>
        -int loglevel
        +debug()
        +info()
        +warning()
        +error()
    }
}

Loading

taskmaster's Issues

Implement Epoll for nonblocking backend

Iterate over the naive implementation with a more robust approach

front end help command

Appropriate help text for error. Ex:

• InvalidCommand -> help.commads()
• InvalidArgument -> help.feature(command)

Integration with rustdocs??

Project UML diagrams

Readme with the following:

• mermaid class diagrams
• application flowchart

Unattach support

Zero supporting structure to unattach from program, need to rework the code and supporting structs

Implement epoll for client

It should facilitate the client to receive updates from a program without the need for STDIN input

Blockers #22

Cmd::Status

starting data structures

We need the parsed config information to be represented into relevant data structures for our program to work.

Cmd::Log

Command handling logic

• #39
• #40
• #41
• #42
• #43

remove stdin handling from multiplexer

Not viable to implement a shell interpreter when we receive input only when the user inserts a newline.

front end autocomplete

Cmd::Other (commands for the attached program)

Handle sub-processes deaths

Cmd::Attach

front end history

Process Stdout and err log management

Required by #39

We need to create log files for each process so we can retrieve them for the LOG/HEAD commands.

Connect daemon with ctl

We need a bidirectional UNIX socket between front and backend of our supervisor.

We're interested in the infrastructure so dumping the content should be enough for now

Logging System Prototype

The logging emit function will have the following prototype:

fn emit(msg: &str, program: &Program)

It can be reasonably hard coded.

basic format should be [$datetime] $log_level $program $msg

Might be necessary to thread the monitoring feature later? Plan accordingly

CmdError should probably be RequestError

It is the backend and / or its requests that give meaning to the commands.

minimal interactive shell

User should be able to prompt an interactive shell with at least one command or check the status of a program

Cmd::Head

Mid attachment request logic

When the client's request is attached it should respond only with the attached program's output

Unsure if bool request finished status is enough to support this behaviour

establish communcation protocol

Define the standard for communication between front-back end.

Statuses?
Headers?
Content?

Common interfaces should be in the appropriate crates.

parametrize daemon config file from argv

minimal config parsing

Parse a YAML file into the necessary requirements for our supervisor to work

These include:

• The command to use to launch the program
• The number of processes to start and keep running
• Whether to start this program at launch or not
• Whether the program should be restarted always, never, or on unexpected exits only
• Which return codes represent an "expected" exit status
• How long the program should be running after it’s started for it to be considered "successfully started"
• How many times a restart should be attempted before aborting
• Which signal should be used to stop (i.e. exit gracefully) the program
• How long to wait after a graceful stop before killing the program
• Options to discard the program’s stdout/stderr or to redirect them to files
• Environment variables to set before launching the program
• A working directory to set before launching the program
• An umask to set before launching the program

start at least one program in background

We need at least a single program running in the background and being monitored by our supervisor.

It can be hardcoded but should at least use the existing interfaces.

read_to_string returns 0

When connection is dropped by client read_to_string returns 0 independently and errno is not updated. Need to investigate how to recover the correct error.

Colorized logging

easier to read stuff

adapt server for attachment

Establish how the front end requests an attachment to a process and synchronize front and backend to know they are operating on this new mode.

EPOLLIN and EPOLLOUT will need to be handled differently by both ends in that case.