Arranger Service¶
Configuration¶
This module has a configuration file (arranger.yaml
by default)
that describes the host, port, ssl_context, trusted_authorities, and
logfile to use. It can also enable insecure logins. It can also change
the service limits.
If no configuration file is found it will default to the following values:
apiVersion: opentestfactory.org/v1beta2
kind: ServiceConfig
current-context: default
contexts:
- context:
port: 443
host: 127.0.0.1
ssl_context: adhoc
eventbus:
endpoint: https://127.0.0.1:38368
token: invalid
max_jobs: 1024
max_job_steps: 10240
max_workers: 4
default_timeout_minutes: 360
name: default
ssl_context
is either adhoc
, a list of two items (certificate file
path and private key file path), or disabled
(not recommended, will
switch to plain HTTP).
A context can also contain a trusted_authorities
, which is a list of
public key files, used for token validation.
A context can also allow for insecure (token-less) logins, if
enable_insecure_login
is set to true
(by default, insecure logins are
disabled).
Insecure logins, if enabled, are only allowed from a given address (127.0.0.1
by default). This can be overridden by specifying insecure_bind_address
.
Workflow limits¶
All those limits must be integers. If the entry is missing, the default value will be assumed.
max_jobs
limits the number of jobs in a workflow. If a workflow contains or
generate more than this limit, the workflow will be cancelled. If not specified,
defaults to 1024.
max_job_steps
limits the number of steps in a workflow. If a job contains or
generate more than this limit, the job will be cancelled. If not specified,
defaults to 10240.
max_workers
limits the number of jobs in a workflow that can be running at
any given time. If not specified, defaults to 4.
default_timeout_minutes
is the default maximum duration for a job, in minutes.
If not specified, defaults to 360 minutes.
Usage¶
python3 -m opentf.core.arranger [--context context] [--config configfile]
Endpoints¶
This module exposes one endpoint:
/inbox
(POST)
Whenever calling this endpoint, a signed token must be specified
via the Authorization
header.
This header will be of form:
Authorization: Bearer xxxxxxxx
It must be signed with one of the trusted authorities specified in the current context.