tt daemon

[unera]

The module is used to start (not use) supervisor daemon.

• tt tvisord [supervisors options]

Config options:

# tarantool.yaml
tvisord:
   port: 3201   # default value
   tls:  # optional
      cert: path/to
      key: path/to
   pid: path/to/tvisord.pid
   log:
      type: file # disabled, syslog
      dir: path/to/logdir

Options:

• --port - listen port
• --tls{-cert,-key} - TLS options

How to work:

1. It runs HTTP[S] server that listens tvisord.port
2. Provide easy protocol

Request:

POST /tt/etc/tarantool HTTP/1.0
Content-Type: application/json

{
    "module": "version",
    "root": "/etc/tarantool",
    "args": [],
    "opts": { "short": true }
}

Response:

200 Ok
Content-Type: application/json

{
   "status": "ok",
   "version": "2.3.4.5"
}

3. The server runs tt module (using ENV=TVISORD=yaml). Parse its output and response.

Authorisation and authentication

TODO: To auth, the server uses tt tvisorauth
Update: see #23

[unera]

• tt tvisord start
• tt tvisord stop
• tt tvisord status
• tt tvisord logrotate
• etc

[LeonidVas]

It was decided to rename the tvisord module to visor.
The visor module is a simple HTTP server without some functionality for managing instances (unlike the tvisor) . And it seems like we can just inject the HTTP part of tvisor to implement the visor module.
The visor module has a separate config and can be start one to many bundles and use the binaries files according to bundle when interacting with the instance.

[LeonidVas]

[Mons]

Why so ugly name for option?

tvisor stands for tarantool visor. but tt itself already a shortcut for tarantool.
I propose to use visor, not tvisord

[Totktonada]

I would go beyond and name it tt daemon, because, well, it does not supervising tarantool instances in the new design (a watchdog does).