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.
Make sure to install all the necessary ForML components before proceeding to the next sections.
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):
The system-wide global configuration directory
User home directory configuration (unless overridden by the
Environment variable driven location of the user configuration directory
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
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
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:
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
defaultkeyword to preselect a configuration instance for situations when no explicit choice is specified during some particular execution.
FEEDprovider type can specify a list of multiple instances as default (contextual feed selection is then performed at runtime).
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
Each configuration instance must point to its provider implementation using the
providerkeyword. 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
the convenient shortcut (if defined by its implementer) - i.e.
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.pathso 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.
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.
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
Spinning up the serving engine using a particular application gateway provider.
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¶
Following is the list of core ForML exceptions emitted at runtime:
- class forml.MissingError[source]¶
Exception state of a missing element.
- class forml.UnexpectedError[source]¶
Exception state of an unexpected element.
- class forml.FailedError[source]¶
Exception indicating an unsuccessful operation result.