Resource definitions describe Hydrosphere entities.
An entity could be your model, application, or deployment configuration. Each definition is represented by a .yaml file.
Base definition
Every definition must include the following fields:
kind: defines the type of a resource
name: defines the name of a resource
The only valid options for kind are:
A model definition must contain the following fields:
runtime: a string defining the runtime Docker image that will be used to run a model. You can learn more about runtimes .
contract: an object defining the inputs and outputs of a model.
A model definition can contain the following fields:
payload: a list of files that should be added to the container.
install-command: a string defining a command that should be executed during the container build.
The example below shows how a model can be defined on the top level.
Contract object
contract object must contain the following fields:
inputs: an object, defining all inputs of a model
outputs: an object, defining all outputs of a model
contract object can contain the following fields:
name: a string defining the signature of the model that should be used to process requests
field object must contain the following fields:
shape: either "scalar" or a list of integers, defining the shape of your data. If a shape is defined as a list of integers, it can have -1 value at the very beginning of the list, indicating that this field has an arbitrary number of "entities". -1 cannot be put anywhere aside from the beginning of the list.
type: a string defining the type of data.
field object can contain the following fields:
profile: a string, defining the profile type of your data.
The only valid options for type are:
string β String in bytes
half β 16-bit half-precision floating-point
The only valid options for profile are:
text β monitoring such fields will be done with text-oriented algorithms.
image β monitoring such fields will be done with image-oriented algorithms.
numerical β monitoring such fields will be done with numerical-oriented algorithms.
The example below shows how a contract can be defined on the top level.
Metadata object
metadata object can represent any arbitrary information specified by the user. The structure of the object is not strictly defined. The only constraint is that the object must have a key-value structure, where a value can only be of a simple data type (string, number, boolean).
The example below shows, how metadata can be defined.
The example below shows a complete definition of a sample model.
kind: Application
The application definition must contain one of the following fields:
singular: An object, defining a single-model application;
pipeline: A list of objects, defining an application as a pipeline of models.
Singular object
singular object represents an application consisting only of one model. The object must contain the following fields:
model: A string, defining a model version. It is expected to be in the form model-name:model-version.
The example below shows how a singular application can be defined.
Pipeline object
pipeline represents a list of stages, representing models.
stage object must contain the following fields:
model: A string defining a model version. It is expected to be in the form model-name:model-version.
stage object can contain the following fields:
weight: A number defining the weight of the model. All models' weights in a stage must add up to 100.
The example below shows how a pipeline application can be defined.
In this application, 100% of the traffic will be forwarded to the claims-preprocessing:1 model version and the output will be fed into claims-model. 80% of the traffic will go to the claims-model:1 model version, 20% of the traffic will go to the claims-model:2 model version.
kind: DeploymentConfiguration
The DeploymentConfiguration resource definition can contain the following fields:
container: An object defining settings applied on a container level
The hpa object closely resembles the Kubernetes object
The hpa object must contain:
minReplicas : minReplicas is the lower limit for the number of replicas to which the autoscaler can scale down.
maxReplicas : integer, upper limit for the number of pods that can be set by the autoscaler; cannot be smaller than minReplicas.
Container object
The container object can contain:
resources : object with limits and requests fields. Closely resembles the k8s object
env : object with string keys and string values which is used to set environment variables.
The hpa object is similar to the Kubernetes object.
The pod object can contain
nodeSelector : which must be true for the pod to fit on a node. Selector which must match a node's labels for the pod to be scheduled on that node. .
affinity : pod's scheduling constraints. Represented by an object.
Deployment object
The deployment object must contain:
replicaCount : integer, number of desired pods. This is a pointer to distinguish between explicit zero and not specified. Defaults to 1.
The example below shows how a deployment configuration can be defined.