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):
Location |
Meaning |
---|---|
|
The system-wide global configuration directory |
|
User home directory configuration (unless overridden by the |
|
Environment variable driven location of the user configuration directory |
Note
Both the system and the user configuration locations are also appended to the runtime
sys.path
so any python modules stored in the configuration directories are
potentially importable. This can be useful for custom provider
implementations.
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 |
|
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 providersRUNNER
- for Pipeline runner providersFEED
- for Source feed providersSINK
- for Output sink providersINVENTORY
- for Application inventory providersGATEWAY
- 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 theforml.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:
Command Group |
Related Chapters |
---|---|
|
|
|
|
|
Common Runtime Features¶
Core Exceptions¶
Following is the list of core ForML exceptions emitted at runtime:
- 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.