Runtime Platform¶

ForML platform is an environment configured to allow performing particular life cycle actions on a general ForML project. Thanks to the pluggable provider architecture, a ForML platform can be built up using a number of different technologies optimized for specific use cases while keeping the same interface and thus guaranteeing the portability of the implemented projects.

Setup¶

Make sure to install all the necessary ForML components before proceeding to the next sections.

Configuration File¶

ForML platform uses the TOML file format for its configuration. The system will try to locate and merge the config.toml file instances in the following directories (in order of parsing/merging - later overrides previous):

Following is the default content of the ForML platform configuration file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

[LOGGING]
# name (will be searched within the config locations) or absolute path
# of the logger config file
config = "logging.ini"

[TEMPLATING]
# name (will be searched within the config locations) or absolute path
# of the project templates directory
path = "templates"
# name of the default template
default = "default"

[RUNNER]
default = "dask"

[RUNNER.dask]
provider = "dask"
scheduler = "processes"

[RUNNER.spark]
provider = "spark"

[RUNNER.graphviz]
provider = "graphviz"
format = "svg"

[RUNNER.pyfunc]
provider = "pyfunc"


[REGISTRY]
default = "homedir"

[REGISTRY.volatile]
provider = "volatile"

[REGISTRY.homedir]
provider = "posix"
#path = ~/.forml/registry


[SINK]
default = "stdout"
apply = "stdout"
eval = "stdout"

[SINK.stdout]
provider = "stdout"

[SINK.null]
provider = "null"


[INVENTORY]
default = "homedir"

[INVENTORY.homedir]
provider = "posix"
#path = ~/.forml/inventory


[GATEWAY]
default = "rest"

[GATEWAY.rest]
provider = "rest"

Providers Settings¶

The majority of the configuration file deals with setting up all the different providers. The file can contain multiple instances of preconfigured providers ready to be selected for a particular execution.

The common structure for the provider configuration sections is:

[<PROVIDER TYPE>]
default = "<instance alias>"

[<PROVIDER TYPE>.<instance alias>]
provider = "<provider reference>"
<provider option X> = <value X>
...

The meaning of the different placeholders and keywords is:

<PROVIDER TYPE>:

One of the six types of provider abstractions used by ForML in uppercase:

• REGISTRY - for Model registry providers

• RUNNER - for Pipeline runner providers

• FEED - for Source feed providers

• SINK - for Output sink providers

• INVENTORY - for Application inventory providers

• GATEWAY - for Serving gateway providers

Each of the provider-type root sections nominates one of its instances using the default keyword to preselect a configuration instance for situations when no explicit choice is specified during some particular execution.

Note

The FEED provider type can specify a list of multiple instances as default (contextual feed selection is then performed at runtime).

<instance alias>:

Each of the individual provider configuration instances is identified using its arbitrary alias. This alias can also be used later to explicitly choose some particular configuration instance when triggering an execution (i.e. using the -R CLI argument).

<provider reference>:

Each configuration instance must point to its provider implementation using the provider keyword. The reference can have one of two potential forms:

• the canonical fully qualified class name specified as <full.module.path>:<class.name> - for example the forml.provider.runner.dask:Runner

• the convenient shortcut (if defined by its implementer) - i.e. dask

Caution

Shortcut references can only be used for auto-discovered provider implementations (typically those shipped with ForML). Any external implementations can only be referenced using the canonical form (plus the referred provider module must be on sys.path so that it can be imported).

<provider option X>:

Any other options specified within the provider configuration instance section are considered to be arbitrary arguments specific to the given provider implementation and will be passed to its constructor.

Logging¶

The python logger is used throughout the framework to emit various logging messages. The logging configuration can be customized using a special configuration file referenced in the top-level logcfg option in the main config.toml.

Execution Mechanisms¶

ForML is using the pluggable pipeline runners to perform all the possible life cycle actions. There are three different mechanisms to carry out the execution:

• The command-line driven batch processing.

• Execution in the interactive mode using the Virtual launcher.

• Spinning up the serving engine using a particular application gateway provider.

Command-line Interface¶

The life cycle management can be fully operated in batch mode using the command-line interface - see the integrated help for more details:

$ forml --help
Usage: forml [OPTIONS] COMMAND [ARGS]...

  Life Cycle Management for Data Science Projects.

Options:
  -C, --config FILE               Additional configuration file.
  -L, --loglevel [debug|info|warning|error]
                                  Global loglevel to use.
  --logfile FILE                  Logfile path.
  --help                          Show this message and exit.

Commands:
  application  Application command group.
  model        Model command group (production life cycle).
  project      Project command group (development life cycle).

Further details on the individual command groups can also be found in the following related chapters:

Common Runtime Features¶

Core Exceptions¶

Following is the list of core ForML exceptions emitted at runtime:

class forml.AnyError[source]¶

Base ForML exception type.

class forml.InvalidError[source]¶

Bases: AnyError

Base invalid state exception.

class forml.MissingError[source]¶

Bases: InvalidError

Exception state of a missing element.

class forml.UnexpectedError[source]¶

Bases: InvalidError

Exception state of an unexpected element.

class forml.FailedError[source]¶

Bases: AnyError

Exception indicating an unsuccessful operation result.

Runtime Performance Metric¶

class forml.runtime.Stats[source]¶

Runtime performance metrics report.

Todo

Complete the Stats concept.