diff --git a/docs/analytics.md b/docs/analytics.md index e16cfa56fb..9135840c4d 100644 --- a/docs/analytics.md +++ b/docs/analytics.md @@ -22,7 +22,7 @@ Each metric has the following key value pairs for further filtering which will b * predictor_version * This will be derived from the predictor metadata labels * model_name - * model_image + * model_image * model_image @@ -39,8 +39,8 @@ helm install seldon-core-analytics --name seldon-core-analytics \ The available parameters are: - * ```grafana_prom_admin_password``` : The admin user grafana password to use. - * ```persistence.enabled``` : Whether prometheus persistence is enabled. + * ```grafana_prom_admin_password``` : The admin user Grafana password to use. + * ```persistence.enabled``` : Whether Prometheus persistence is enabled. Once running you can expose the Grafana dashboard with: diff --git a/docs/articles/openshift_s2i.md b/docs/articles/openshift_s2i.md index d02613b1f0..3a4c91f15d 100644 --- a/docs/articles/openshift_s2i.md +++ b/docs/articles/openshift_s2i.md @@ -1,17 +1,17 @@ # Using Openshift Source-to-Image to facilitate Machine Learning Deployment -Seldon aims to help oraganisations put their data science projects into production so they can decrease the time to get return on investment. By helping data scientists take their data science models and place them into production, scale them, get analytics and modify them Seldon allows data scientists to bridge the gap from development to production and use current dev-ops best practices in machine learning. Our core products run on top of Kubernetes and can be deployed on-cloud on on-premise. Integrating with enterprise ready Kubernetes distributions such as Openshift allows us to provide a solid foundation in which to supply our products for use in demanding verticals such as the FinTech sector. +Seldon aims to help organisations put their data science projects into production so they can decrease the time to get return on investment. By helping data scientists take their data science models and place them into production, scale them, get analytics and modify them Seldon allows data scientists to bridge the gap from development to production and use current dev-ops best practices in machine learning. Our core products run on top of Kubernetes and can be deployed on-cloud on on-premise. Integrating with enterprise ready Kubernetes distributions such as Openshift allows us to provide a solid foundation in which to supply our products for use in demanding verticals such as the FinTech sector. [Seldon-Core](https://github.com/SeldonIO/seldon-core) is an open source project that provides scalable machine learning deployment running on [Kubernetes](https://kubernetes.io/). One of Seldon-Core’s goals is to allow data scientists to continue to construct their training and inference components using any of the many available machine learning toolkits, be that python based (e.g., TensorFlow, sklearn), R or Java (e.g., Spark, H2O) amongst many popular options. Seldon-Core will then allow them easily to package and run their runtime prediction modules on Kubernetes. To achieve this goal we need to make it easy for data scientists to take their source code and package it as a Docker-formatted container in the correct form such that it can be managed as part of a runtime microservice graph on Kubernetes by Seldon-Core. For this we utilize Openshift’s Source-to-Image open source library to allow any code to be packaged in the correct format with minimal requirements from the data scientist. # Seldon-Core Overview -Seldon-core provides scalebale machine learning deployments running on Kubernetes. To deploy their models data scientists follow the steps as shown below: +Seldon-core provides scalable machine learning deployments running on Kubernetes. To deploy their models data scientists follow the steps as shown below: ![API](../deploy.png) 1. Package their runtime model as a Docker-formatted image - 1. Describe their runtime graph as a kubernetes resource - 1. Deploy to kubernetes using standard tools such as kubectl, Helm, ksonnet. + 1. Describe their runtime graph as a Kubernetes resource + 1. Deploy to Kubernetes using standard tools such as kubectl, Helm, ksonnet. Once running their deployment can be updated as new image releases are created for the runtime model as well as updates to the runtime graph. @@ -26,7 +26,7 @@ The types of component you can create can include: * Combiners - e.g., Model ensemblers * Transformers - e.g., Feature normalization, Outlier detection, concept drift -As the above diagram shows these need to be fitted into the microservice API of seldon-core either as REST or gRPC services. +As the above diagram shows these need to be fitted into the microservice API of seldon-core either as REST or gRPC services. # Source-to-Image integration To integrate a component into seldon-core the data scientist needs to accomplish two things: @@ -52,10 +52,10 @@ class MyModel(object): """ Model template. You can load your model parameters in __init__ from a location accessible at runtime """ - + def __init__(self): """ - Add any initialization parameters. These will be passed at runtime from the graph definition parameters defined in your seldondeployment kubernetes resource manifest. + Add any initialization parameters. These will be passed at runtime from the graph definition parameters defined in your seldondeployment Kubernetes resource manifest. """ print("Initializing") @@ -76,9 +76,9 @@ class MyModel(object): * The class contains a predict method that takes an array (numpy) X and feature_names and returns an array of predictions. * Any required initialization can be put inside the class init method. -An optional requirements.txt can detail any software dependencies the code requires. +An optional requirements.txt can detail any software dependencies the code requires. -To allow the s2i builder image to correctly package the component the data scinetist needs to provide a few environment variables either in an .s2i/environment file in the source code folder or on the command line. An example is: +To allow the s2i builder image to correctly package the component the data scientist needs to provide a few environment variables either in an .s2i/environment file in the source code folder or on the command line. An example is: ```bash MODEL_NAME=MyModel @@ -94,7 +94,7 @@ s2i build seldonio/seldon-core-s2i-python2 ``` ## R -R is a popular statistical langiage which provides many machine learning related packages. +R is a popular statistical language which provides many machine learning related packages. To use the seldon s2i builder image to package an R model the requirements are: @@ -102,7 +102,7 @@ To use the seldon s2i builder image to package an R model the requirements are: * An optional install.R to be run to install any libraries needed * .s2i/environment - model definitions used by the s2i builder to correctly wrap your model -The data scientist's source code should contain an R file which defines an S3 class for their model. For example, +The data scientist's source code should contain an R file which defines an S3 class for their model. For example, ```R library(methods) @@ -140,9 +140,9 @@ API_TYPE=REST SERVICE_TYPE=MODEL ``` -These values can also be provided in an .s2i/environment file with the source code or overriden on the command line when building the image. +These values can also be provided in an .s2i/environment file with the source code or overridden on the command line when building the image. -Once these steps are done we can use ```s2i build``` to create the Docker-formatted image from the source code. +Once these steps are done we can use ```s2i build``` to create the Docker-formatted image from the source code. ```bash s2i build seldonio/seldon-core-s2i-r @@ -158,14 +158,14 @@ s2i build https://github.com/seldonio/seldon-core.git --context-dir=wrappers/s2i ## Java There are several popular machine learning libraries in Java including Spark, H2O and DL4J. Seldon-core also provides builder images for Java. To accomplish this we provide a Java library seldon-core-wrappers that can be included in a Maven Spring project to allow a Java component to be easily wrapped. -To use teh Seldon-Core s2i builder image to package a Java model the data scientist will need: +To use the Seldon-Core s2i builder image to package a Java model the data scientist will need: * A Maven project that depends on the ```io.seldon.wrapper``` library * A Spring Boot configuration class * A class that implements ```io.seldon.wrapper.SeldonPredictionService``` for the type of component you are creating * An optional .s2i/environment - model definitions used by the s2i builder to correctly wrap your model -More details can be found in the seldon-core docs +More details can be found in the seldon-core docs. # Summary diff --git a/docs/articles/release-0.2.3.md b/docs/articles/release-0.2.3.md index adf81d2e1a..d198eb2e37 100644 --- a/docs/articles/release-0.2.3.md +++ b/docs/articles/release-0.2.3.md @@ -44,7 +44,7 @@ spec: We have an external contribution by @SachinVarghese that provides an initial Seldon Core wrapper for NodeJS allowing you to take advantage of the emerging machine learning tools within the Javascript ecosystem. Thanks Sachin! -An example notebook for an [MNIST Tensorflow model](https://github.com/SeldonIO/seldon-core/blob/master/examples/models/nodejs_tensorflow/nodejs_tensorflow.ipynb) is provided which has the following javascript inference code: +An example notebook for an [MNIST Tensorflow model](https://github.com/SeldonIO/seldon-core/blob/master/examples/models/nodejs_tensorflow/nodejs_tensorflow.ipynb) is provided which has the following Javascript inference code: ``` const tf = require("@tensorflow/tfjs"); diff --git a/docs/benchmarking.md b/docs/benchmarking.md index d551a28efc..b713c95221 100644 --- a/docs/benchmarking.md +++ b/docs/benchmarking.md @@ -1,6 +1,6 @@ # Seldon-core Benchmarking -This page is a work in progress to provide benchmarking stats for seldon-core. Please add further ideas and suggestions as an issue. +This page is a work in progress to provide benchmarking stats for seldon-core. Please add further ideas and suggestions as an issue. ## Goals @@ -11,7 +11,7 @@ This page is a work in progress to provide benchmarking stats for seldon-core. ## Components * We use [locust](https://locust.io/) as our benchmarking tool. - * We use Google Cloud Platform for the infrastructure to run kubernetes. + * We use Google Cloud Platform for the infrastructure to run Kubernetes. # Tests @@ -22,11 +22,11 @@ To gauge the maximum throughput we will: * Call the seldon engine component directly thereby ignoring the additional latency that would be introduced by an external reverse proxy (Ambassador) or using the built in seldon API Front-End Oauth2 component. * Utilize a "stub" model that does nothing but return a hard-wired result from inside the engine. -This test will illustrate the maximum number of requests that can be pushed through seldon-core engine (which controls the request-response flow) as well as the added latency for the processing of REST and gRPC requests, e.g. serialization / deserialization. +This test will illustrate the maximum number of requests that can be pushed through seldon-core engine (which controls the request-response flow) as well as the added latency for the processing of REST and gRPC requests, e.g. serialization/deserialization. -We will use cordened off kubernetes nodes running locust so the latency from node to node prediction calls on GCP will also be part of the returned statistics. +We will use cordoned off Kubernetes nodes running locust so the latency from node to node prediction calls on GCP will also be part of the returned statistics. -A [notebook](https://github.com/SeldonIO/seldon-core/blob/master/notebooks/benchmark_simple_model.ipynb) provides the end to end test for reproducability. +A [notebook](https://github.com/SeldonIO/seldon-core/blob/master/notebooks/benchmark_simple_model.ipynb) provides the end to end test for reproducibility. We use: diff --git a/docs/challenges.md b/docs/challenges.md index 3bdf9aa74b..9e8d87ef85 100644 --- a/docs/challenges.md +++ b/docs/challenges.md @@ -2,7 +2,7 @@ Machine Learning deployment has many challenges which Seldon Core's goals are to solve, these include: - * Allow a wide range of ML modeling tools to be easily deployed, e.g. Python, R, Spark, and propritary models + * Allow a wide range of ML modelling tools to be easily deployed, e.g. Python, R, Spark, and proprietary models * Launch ML runtime graphs, scale up/down, perform rolling updates * Run health checks and ensure recovery of failed components * Infrastructure optimization for ML @@ -17,11 +17,11 @@ Machine Learning deployment has many challenges which Seldon Core's goals are to * Asynchronous * Batch * Allow Auditing and clear versioning - * Integrate into Continuous Integration (CI) + * Integrate into Continuous Integration (CI) * Allow Continuous Deployment (CD) * Provide Monitoring * Base metrics: Accuracy, request latency and throughput - * Complex metrics: + * Complex metrics: * Concept drift * Bias detection * Outlier detection diff --git a/docs/crd/readme.md b/docs/crd/readme.md index 65a875529a..c47f692fdf 100644 --- a/docs/crd/readme.md +++ b/docs/crd/readme.md @@ -24,7 +24,7 @@ message SeldonDeployment { } ``` -The core deployment spec consists of a set of ```predictors```. Each predictor represents a seperate runtime serving graph. The set of predictors will serve request as controlled by a load balancer. At present the share of traffic will be in relation to the number of replicas each predictor has. A use case for two predictors would be a main deployment and a canary, with the main deployment having 9 replicas and the canary 1, so the canary receives 10% of the overall traffic. Each predictor will be a seperately set of managed deployments with Kubernetes so it is safe to add and remove predictors without affecting existing predictors. +The core deployment spec consists of a set of ```predictors```. Each predictor represents a separate runtime serving graph. The set of predictors will serve request as controlled by a load balancer. At present the share of traffic will be in relation to the number of replicas each predictor has. A use case for two predictors would be a main deployment and a canary, with the main deployment having 9 replicas and the canary 1, so the canary receives 10% of the overall traffic. Each predictor will be a separately set of managed deployments with Kubernetes so it is safe to add and remove predictors without affecting existing predictors. To allow an OAuth API to be provisioned you should specify an OAuth key and secret. If you are using Ambassador you will not need this as you can plug in your own external authentication using Ambassador. @@ -44,7 +44,7 @@ For each predictor you should at a minimum specify: * A unique name * A PredictiveUnit graph that presents the tree of components to deploy. - * One or more componentSpecs which describes the set of images for parts of your container graph that will be instigated as microservice containers. These containers will have been wrapped to work within the [internal API](../reference/internal-api.md). This component spec is a standard [PodTemplateSpec](https://kubernetes.io/docs/api-reference/extensions/v1beta1/definitions/#_v1_podtemplatespec). For complex grahs you can decide to use several componentSpecs so as to separate your components into separate Pods each with their own resource requirements. + * One or more componentSpecs which describes the set of images for parts of your container graph that will be instigated as microservice containers. These containers will have been wrapped to work within the [internal API](../reference/internal-api.md). This component spec is a standard [PodTemplateSpec](https://kubernetes.io/docs/api-reference/extensions/v1beta1/definitions/#_v1_podtemplatespec). For complex graphs you can decide to use several componentSpecs so as to separate your components into separate Pods each with their own resource requirements. * If you leave the ports empty for each container they will be added automatically and matched to the ports in the graph specification. If you decide to specify the ports manually they should match the port specified for the matching component in the graph specification. * the number of replicas of this predictor to deploy @@ -56,20 +56,20 @@ message PredictorSpec { optional int32 replicas = 4; // The number of replicas of the predictor to create. map annotations = 5; // Arbitrary annotations. optional k8s.io.api.core.v1.ResourceRequirements engineResources = 6; // Optional set of resources for the Seldon engine which is added to each Predictor graph to manage the request/response flow - map labels = 7; // labels to be attached to entry deplyment for this predictor + map labels = 7; // labels to be attached to entry deployment for this predictor } ``` -The predictive unit graph is a tree. Each node is of a particular type. If the implementation is not specified then a microservice is assumed and you must define a matching named container within the componentSpec above. Each type of PredictiveUnit has a standard set of methods it is expected to manage, see [here](../reference/seldon-deployment.md). +The predictive unit graph is a tree. Each node is of a particular type. If the implementation is not specified then a microservice is assumed and you must define a matching named container within the componentSpec above. Each type of PredictiveUnit has a standard set of methods it is expected to manage, see [here](../reference/seldon-deployment.md). For each node in the graph: * A unique name. If the node describes a microservice then it must match a named container with the componentSpec. * The children nodes. * The type of the predictive unit : MODEL, ROUTER, COMBINER, TRANSFORMER or OUTPUT_TRANSFORMER. - * The implementation. This can be left blank if it will be a microserice as this is the default otherwise choose from the available appropriate implementations provided internally. - * Methods. This can be left blank if you wish to follow the standard methods for your PredictiveNode type : see [here](../reference/seldon-deployment.md). + * The implementation. This can be left blank if it will be a microservice as this is the default otherwise choose from the available appropriate implementations provided internally. + * Methods. This can be left blank if you wish to follow the standard methods for your PredictiveNode type : see [here](../reference/seldon-deployment.md). * Endpoint. In here you should minimally if this a microservice specify whether the PredictiveUnit will use REST or gRPC. Ports will be defined automatically if not specified. * Parameters. Specify any parameters you wish to pass to the PredictiveUnit. These will be passed in an environment variable called PREDICTIVE_UNIT_PARAMETERS as a JSON list. diff --git a/docs/deploying.md b/docs/deploying.md index 6b7a08dc1e..e80735ada5 100644 --- a/docs/deploying.md +++ b/docs/deploying.md @@ -1,6 +1,6 @@ # Deployment -You can manage your deployments via the standard kubernetes CLI kubectl, e.g. +You can manage your deployments via the standard Kubernetes CLI kubectl, e.g. ```bash kubectl apply -f my_ml_deployment.yaml @@ -14,8 +14,8 @@ For production settings you will want to incorporate your ML infrastructure and The pipeline consists of * A model code repo (in Git) where training and runtime ML components are stored - * A continuuous integration pipeline that will train and test the model and wrap it (using Seldon built-in Wrappers or custome wrappers) + * A continuous integration pipeline that will train and test the model and wrap it (using Seldon built-in Wrappers or custom wrappers) * An image repository where the final runtime inference model image is stored. * A git repo for the infrastructure to store the ML deployment graph described as a SeldonDeployment - * Some tool to either monitor the infrastructure repo and apply to the production kubernetes changes or a tool to allow dev ops to push updated infrastructure manually. + * Some tool to either monitor the infrastructure repo and apply to the production Kubernetes changes or a tool to allow dev ops to push updated infrastructure manually. diff --git a/docs/examples/h2oexample.md b/docs/examples/h2oexample.md index 77a6a41349..16f6103094 100644 --- a/docs/examples/h2oexample.md +++ b/docs/examples/h2oexample.md @@ -4,15 +4,15 @@ date: 2017-12-09T17:49:41Z --- -In this readme we outline the steps needed to wrap any h2o model using seldon python wrappers into a docker image deployable with seldon core. +In this readme we outline the steps needed to wrap any h2o model using seldon python wrappers into a docker image deployable with seldon core. -The file H2oModel.py is a template to use in order to wrap a h2o model. The only modification required on the user side consists of setting the MODEL_PATH variable at the top of the file as explained below in session "Wrap" at point 2. +The file H2oModel.py is a template to use in order to wrap a h2o model. The only modification required on the user side consists of setting the MODEL_PATH variable at the top of the file as explained below in session "Wrap" at point 2. -We also provide a script to train and save a prebuilded h2o model predicting bad loans. +We also provide a script to train and save a pre-built h2o model predicting bad loans. The session "General use" explain how to use the wrapper with any saved h2o model. -The session "Example of usage" provides a step-by-step guide for training, deploying and wrap the prebuilded h2o model for bad loans predictions as an example. +The session "Example of usage" provides a step-by-step guide for training, deploying and wrap the pre-built h2o model for bad loans predictions as an example. ## General use @@ -20,8 +20,8 @@ The session "Example of usage" provides a step-by-step guide for training, deplo 1. It is assumed you have already trained a h2o model and saved it in a file \ using the ```h2o.save_model()``` python function. * You have cloned the latest version of seldon-core git repository. -* You have a python+java docker image avaliable to use as base-image. One way to build a suitable base-image locally is by using the [Dockerfile provided by h2o](https://h2o-release.s3.amazonaws.com/h2o/rel-turing/1/docs-website/h2o-docs/docker.html): - * Make sure you have docker deamon running. +* You have a python+java docker image available to use as base-image. One way to build a suitable base-image locally is by using the [Dockerfile provided by h2o](https://h2o-release.s3.amazonaws.com/h2o/rel-turing/1/docs-website/h2o-docs/docker.html): + * Make sure you have docker daemon running. * Download the [Dockerfile provided by h2o](https://h2o-release.s3.amazonaws.com/h2o/rel-turing/1/docs-website/h2o-docs/docker.html) in any folder. * Create the base docker image: @@ -31,18 +31,18 @@ The session "Example of usage" provides a step-by-step guide for training, deplo ### Wrap: -You can now wrap the model using seldon python wrappers. +You can now wrap the model using seldon python wrappers. 1. Copy the files H2oModel.py, requirements.txt and \ in a folder named \ . -* Open the file H2oModel.py with your favorite editor and set the variable MODEL_PATH to: +* Open the file H2oModel.py with your favourite editor and set the variable MODEL_PATH to: - ```MODEL_PATH=/microservice/``` + ```MODEL_PATH=/microservice/``` * Cd into the the python wrapper directory in seldon-core, ```/seldon-core/wrapper/python``` * Use the wrap_model.py script to wrap your model: ```python wrap_model.py H2oModel --base-image --force``` - This will create a "build" directory in \. + This will create a "build" directory in \. * Enter the build directory created by wrap_model.py: ```cd /build``` @@ -60,11 +60,11 @@ You can now deploy the model as a docker image ```/h2omodel: \ --set rbac.enabled= \ - --set ambassador.enabled= + --set ambassador.enabled= ``` Notes * You can use ```--namespace``` to install seldon-core to a particular namespace * For full configuration options see [here](helm.md) - + ## With Ksonnet * [install Ksonnet](https://ksonnet.io/) @@ -62,7 +62,7 @@ cd my-ml-deployment && \ ks generate seldon-core seldon-core \ --withApife= \ --withAmbassador= \ - --withRbac= + --withRbac= ``` * Launch components onto cluster ``` @@ -74,7 +74,7 @@ Notes ## Other Options -### Install with kubeflow +### Install with Kubeflow - * [Install Seldon as part of kubeflow.](https://www.kubeflow.org/docs/guides/components/seldon/#seldon-serving) - * Kubeflow presently runs 0.1 version of seldon-core. This will be updated to 0.2 in the near future. \ No newline at end of file + * [Install Seldon as part of Kubeflow.](https://www.kubeflow.org/docs/guides/components/seldon/#seldon-serving) + * Kubeflow presently runs 0.1 version of seldon-core. This will be updated to 0.2 in the near future. diff --git a/docs/istio.md b/docs/istio.md index 6d4a03adbb..7f5986d92a 100644 --- a/docs/istio.md +++ b/docs/istio.md @@ -1,14 +1,14 @@ # Istio and Seldon -[Istio](https://istio.io/) provides service mesh functionality and can be a useful addition to Seldon to provide extra traffic management, end-to-end security and policy enforcement in your runtime machine learning deployment graph. Seldon-core can be seen as providing a service graph for machine learning deployments. As part of that it provdes an Operator which takes your ML deployment graph definition described as a SeldonDeployment kubernetes resource and deploys and manages it on a kubernetes cluster so you can connect your business applications that need to access machine learning services. Data scientists can focus on building pluggable docker containers for parts of their runtime machine learning graph, such as runtime inference, transformations, outlier detection, ensemblers etc. These can be composed together as needed to satisfy your runtime ML functionality. To allow modules to be built without knowing what service graph they will exist in means Seldon also deploys a Service Orchestrator as part of each deployment which manages the request/reponse flow to satisfy the defined ML service graph for multi-component graphs. +[Istio](https://istio.io/) provides service mesh functionality and can be a useful addition to Seldon to provide extra traffic management, end-to-end security and policy enforcement in your runtime machine learning deployment graph. Seldon-core can be seen as providing a service graph for machine learning deployments. As part of that it provides an Operator which takes your ML deployment graph definition described as a SeldonDeployment Kubernetes resource and deploys and manages it on a Kubernetes cluster so you can connect your business applications that need to access machine learning services. Data scientists can focus on building pluggable docker containers for parts of their runtime machine learning graph, such as runtime inference, transformations, outlier detection, ensemblers etc. These can be composed together as needed to satisfy your runtime ML functionality. To allow modules to be built without knowing what service graph they will exist in means Seldon also deploys a Service Orchestrator as part of each deployment which manages the request/response flow to satisfy the defined ML service graph for multi-component graphs. -The components are illustrated below. A user's graph resource definition (graph.yaml) is sent over the Kubernetes API and the Seldon Operator manages the creation and update of the underlying components including the seldon service orchestrator which manages the request/response flow logic through the deployed graph. +The components are illustrated below. A user's graph resource definition (graph.yaml) is sent over the Kubernetes API and the Seldon Operator manages the creation and update of the underlying components including the Seldon service orchestrator which manages the request/response flow logic through the deployed graph. ![svc-graph](./svc-graph.png) -Out of the box Seldon provides rolling updates to SeldonDeployment service graphs provided by the underlying kubernetes functionality. However, there are cases where you want to manage updates to your ML deployments in a more controlled way with fine grained traffic management including canary updates, blue-green deployments and shadowing. This is where Istio can help in combination with Seldon. +Out of the box Seldon provides rolling updates to SeldonDeployment service graphs provided by the underlying Kubernetes functionality. However, there are cases where you want to manage updates to your ML deployments in a more controlled way with fine grained traffic management including canary updates, blue-green deployments and shadowing. This is where Istio can help in combination with Seldon. -The addition of istio is complementary to Seldon and is illustrated below where Envoy sidecars are injected into the defined Kubernetes Deployments and the user can manage the service mesh using the Istio control plane. +The addition of Istio is complementary to Seldon and is illustrated below where Envoy sidecars are injected into the defined Kubernetes Deployments and the user can manage the service mesh using the Istio control plane. ![svc-graph-istio](./svc-graph-istio.png) diff --git a/docs/private_registries.md b/docs/private_registries.md index 020b06351c..6144f3282d 100644 --- a/docs/private_registries.md +++ b/docs/private_registries.md @@ -1,6 +1,6 @@ # Pulling from Private Docker Registries -To pull images from private Docker registries simply add imagePullSecrets to the podTemplateSpecs for your SeldonDeployment resources. For example, show below is a simple model which uses a private image ```private-docker-repo/my-image```. You will need to have created the kubernetes docker registry secret ```myreposecret``` before applying the resource to your cluster. +To pull images from private Docker registries simply add imagePullSecrets to the podTemplateSpecs for your SeldonDeployment resources. For example, show below is a simple model which uses a private image ```private-docker-repo/my-image```. You will need to have created the Kubernetes docker registry secret ```myreposecret``` before applying the resource to your cluster. ``` { @@ -44,4 +44,4 @@ To pull images from private Docker registries simply add imagePullSecrets to the } ``` -To create the docker registry secret see the [Kubernetes docs](https://kubernetes.io/docs/concepts/containers/images/#creating-a-secret-with-a-docker-config). \ No newline at end of file +To create the docker registry secret see the [Kubernetes docs](https://kubernetes.io/docs/concepts/containers/images/#creating-a-secret-with-a-docker-config). diff --git a/docs/reference/external-prediction.md b/docs/reference/external-prediction.md index 2025898fb0..1f70388a92 100644 --- a/docs/reference/external-prediction.md +++ b/docs/reference/external-prediction.md @@ -10,11 +10,11 @@ The Seldon Core exposes a generic external API to connect your ML runtime predic - endpoint : POST /api/v0.1/predictions - payload : JSON representation of ```SeldonMessage``` - see [proto definition](./prediction.md/#proto-buffer-and-grpc-definition) - - example payload : + - example payload : ```json {"data":{"names":["a","b"],"tensor":{"shape":[2,2],"values":[0,0,1,1]}}} ``` -### Feedback +### Feedback - endpoint : POST /api/v0.1/feedback - payload : JSON representation of ```Feedback``` - see [proto definition](./prediction.md/#proto-buffer-and-grpc-definition) @@ -26,7 +26,7 @@ service Seldon { rpc Predict(SeldonMessage) returns (SeldonMessage) {}; rpc SendFeedback(Feedback) returns (SeldonMessage) {}; } -``` +``` see full [proto definition](./prediction.md/#proto-buffer-and-grpc-definition) diff --git a/docs/reference/internal-api.md b/docs/reference/internal-api.md index f1797f74b2..473734ceac 100644 --- a/docs/reference/internal-api.md +++ b/docs/reference/internal-api.md @@ -13,7 +13,7 @@ To add microservice components to a runtime prediction graph users need to creat ## Model -A service to return predictions. +A service to return predictions. ### REST API @@ -25,7 +25,7 @@ A service to return predictions. | Request | JSON representation of [```SeldonMessage```](./prediction.md/#proto-buffer-and-grpc-definition) | | Response | JSON representation of [```SeldonMessage```](./prediction.md/#proto-buffer-and-grpc-definition) | -Example request payload: +Example request payload: ```json {"data":{"names":["a","b"],"tensor":{"shape":[2,2],"values":[0,0,1,1]}}} @@ -37,7 +37,7 @@ Example request payload: service Model { rpc Predict(SeldonMessage) returns (SeldonMessage) {}; } -``` +``` See full [proto definition](./prediction.md/#proto-buffer-and-grpc-definition). @@ -55,7 +55,7 @@ A service to route requests to one of its children and receive feedback rewards | Request | JSON representation of [```SeldonMessage```](./prediction.md/#proto-buffer-and-grpc-definition) | | Response | JSON representation of [```SeldonMessage```](./prediction.md/#proto-buffer-and-grpc-definition) | -Example request payload: +Example request payload: ```json {"data":{"names":["a","b"],"tensor":{"shape":[2,2],"values":[0,0,1,1]}}} @@ -69,7 +69,7 @@ Example request payload: | Request | JSON representation of [```Feedback```](./prediction.md/#proto-buffer-and-grpc-definition) | | Response | JSON representation of [```SeldonMessage```](./prediction.md/#proto-buffer-and-grpc-definition) | -Example request payload: +Example request payload: ```json "request": { @@ -102,13 +102,13 @@ service Router { rpc Route(SeldonMessage) returns (SeldonMessage) {}; rpc SendFeedback(Feedback) returns (SeldonMessage) {}; } -``` +``` See full [proto definition](./prediction.md/#proto-buffer-and-grpc-definition). ## Combiner -A service to combine reponses from its children into a single response. +A service to combine responses from its children into a single response. ### REST API @@ -127,7 +127,7 @@ A service to combine reponses from its children into a single response. service Combiner { rpc Aggregate(SeldonMessageList) returns (SeldonMessage) {}; } -``` +``` See full [proto definition](./prediction.md/#proto-buffer-and-grpc-definition). @@ -147,7 +147,7 @@ A service to transform its input. | Request | JSON representation of [```SeldonMessage```](./prediction.md/#proto-buffer-and-grpc-definition) | | Response | JSON representation of [```SeldonMessage```](./prediction.md/#proto-buffer-and-grpc-definition) | -Example request payload: +Example request payload: ```json {"data":{"names":["a","b"],"tensor":{"shape":[2,2],"values":[0,0,1,1]}}} @@ -159,7 +159,7 @@ Example request payload: service Transformer { rpc TransformInput(SeldonMessage) returns (SeldonMessage) {}; } -``` +``` See full [proto definition](./prediction.md/#proto-buffer-and-grpc-definition). @@ -179,7 +179,7 @@ A service to transform the response from its child. | Request | JSON representation of [```SeldonMessage```](./prediction.md/#proto-buffer-and-grpc-definition) | | Response | JSON representation of [```SeldonMessage```](./prediction.md/#proto-buffer-and-grpc-definition) | -Example request payload: +Example request payload: ```json {"data":{"names":["a","b"],"tensor":{"shape":[2,2],"values":[0,0,1,1]}}} @@ -191,7 +191,7 @@ Example request payload: service OutputTransformer { rpc TransformOutput(SeldonMessage) returns (SeldonMessage) {}; } -``` +``` See full [proto definition](./prediction.md/#proto-buffer-and-grpc-definition). diff --git a/docs/reference/seldon-deployment.md b/docs/reference/seldon-deployment.md index c23699a563..fed21124c7 100644 --- a/docs/reference/seldon-deployment.md +++ b/docs/reference/seldon-deployment.md @@ -12,7 +12,7 @@ A SeldonDeployment is defined as a custom resource definition within Kubernetes. ## Proto Buffer Definition -The Seldon Deployment Custom Resource is defined using Proto Buffers. +The Seldon Deployment Custom Resource is defined using Proto Buffers. ```proto syntax = "proto2"; @@ -65,7 +65,7 @@ message PredictorSpec { optional int32 replicas = 4; // The number of replicas of the predictor to create. map annotations = 5; // Arbitrary annotations. optional k8s.io.api.core.v1.ResourceRequirements engineResources = 6; // Optional set of resources for the Seldon engine which is added to each Predictor graph to manage the request/response flow - map labels = 7; // labels to be attached to entry deplyment for this predictor + map labels = 7; // labels to be attached to entry deployment for this predictor } @@ -75,7 +75,7 @@ message PredictorSpec { message PredictiveUnit { /** - * The main type of the predictive unit. Routers decide where requests are sent, e.g. AB Tests and Multi-Armed Bandits. Combiners ensemble responses from their children. Models are leaft nodes in the predictive tree and provide request/reponse functionality encapsulating a machine learning model. Transformers alter the request features. + * The main type of the predictive unit. Routers decide where requests are sent, e.g. AB Tests and Multi-Armed Bandits. Combiners ensemble responses from their children. Models are leaf nodes in the predictive tree and provide request/response functionality encapsulating a machine learning model. Transformers alter the request features. */ enum PredictiveUnitType { // Each one of these defines a default combination of Predictive Unit Methods @@ -88,7 +88,7 @@ message PredictiveUnit { } enum PredictiveUnitImplementation { - // Each one of these are hardcoded in the engine, no microservice is used + // Each one of these are hard-coded in the engine, no microservice is used UNKNOWN_IMPLEMENTATION = 0; // No implementation (microservice used) SIMPLE_MODEL = 1; // An internal model stub for testing. SIMPLE_ROUTER = 2; // An internal router for testing. @@ -133,7 +133,7 @@ message Parameter { DOUBLE = 2; STRING = 3; BOOL = 4; - } + } required string name = 1; required string value = 2; @@ -153,7 +153,7 @@ message Parameter { * The model requests 1 MB of memory * The model defines oauth key and secret for use with seldon-core's built in API gateway. * The model supports a REST API - + ```json { "apiVersion": "machinelearning.seldon.io/v1alpha2", @@ -208,4 +208,4 @@ message Parameter { ] } } -``` \ No newline at end of file +``` diff --git a/docs/v1alpha2_update.md b/docs/v1alpha2_update.md index 87b5cba37d..7f94e12b20 100644 --- a/docs/v1alpha2_update.md +++ b/docs/v1alpha2_update.md @@ -1,9 +1,9 @@ # V1Alpha2 Update - * The ```PredictorSpec componentSpec``` is now ```componentSpecs``` and takes a list of ```PodTemplateSpecs``` allowing you to split your runtime graph into separate Kubernetes Deployments as needed. See the new [proto definiton](./proto/seldon_deployment.proto). To update existing resources: + * The ```PredictorSpec componentSpec``` is now ```componentSpecs``` and takes a list of ```PodTemplateSpecs``` allowing you to split your runtime graph into separate Kubernetes Deployments as needed. See the new [proto definition](./proto/seldon_deployment.proto). To update existing resources: * Change ``` "apiVersion": "machinelearning.seldon.io/v1alpha1"``` to ``` "apiVersion": "machinelearning.seldon.io/v1alpha2"``` * Change ```componentSpec``` -> ```componentSpecs``` and enclose the existing ```PodTemplateSpec``` in a single element list - + For example change: ``` @@ -120,4 +120,4 @@ to } } -``` \ No newline at end of file +``` diff --git a/docs/wrappers/h2o.md b/docs/wrappers/h2o.md index b7e1c70455..499403d2cc 100644 --- a/docs/wrappers/h2o.md +++ b/docs/wrappers/h2o.md @@ -1,6 +1,6 @@ # Packaging a H2O model for Seldon Core -This document outlines the steps needed to wrap any H2O model using Seldon's python wrappers into a docker image ready for deployment with Seldon Core. The process is nearly identical to [wrapping a python model with the seldon wrapper](python-docker.md), so be sure to read the documentation on this process first. +This document outlines the steps needed to wrap any H2O model using Seldon's python wrappers into a docker image ready for deployment with Seldon Core. The process is nearly identical to [wrapping a python model with the seldon wrapper](python-docker.md), so be sure to read the documentation on this process first. The main differences are: * The data sent to the model needs to be transformed from numpy arrays into H2O Frames and back; * The base docker image has to be changed, because H2O needs a Java Virtual Machine installed in the container. @@ -14,7 +14,7 @@ You will find below explanations for: In order to wrap a H2O model with the python wrappers, you need a python+java docker image available to use as base image. One way to build a suitable base image locally is by using the [Dockerfile provided by H2O](https://h2o-release.s3.amazonaws.com/h2o/rel-turing/1/docs-website/h2o-docs/docker.html): -* Make sure you have docker deamon running. +* Make sure you have docker daemon running. * Download the [Dockerfile provided by H2O](https://github.com/h2oai/h2o-3/blob/master/Dockerfile) in any folder. * Create the base docker image (we will call it H2OBase:1.0 in this example): @@ -31,24 +31,24 @@ It is assumed you have already trained a H2O model and saved it in a file (calle You can now wrap the model using Seldon's python wrappers. This is similar to the general python model wrapping process except that you need to specify the H2O base image as an argument when calling the wrapping script. -We provide a file [H2OModel.py](https://github.com/SeldonIO/seldon-core/blob/master/examples/models/h2o_example/H2OModel.py) as a template for the model entrypoint, which handles loading the H2OModel and transforming the data between numpy and H2O Frames. In what follows we assume you are using this template. The H2O model is loaded in the class constructor and the numpy arrays are turned into H2O Frames when received in the predict method. +We provide a file [H2OModel.py](https://github.com/SeldonIO/seldon-core/blob/master/examples/models/h2o_example/H2OModel.py) as a template for the model entry point, which handles loading the H2OModel and transforming the data between numpy and H2O Frames. In what follows we assume you are using this template. The H2O model is loaded in the class constructor and the numpy arrays are turned into H2O Frames when received in the predict method. Detailed steps: 1. Put the files H2OModel.py, requirements.txt and SavedModel.h2o in a directory created for this purpose. -2. Open the file H2OModel.py with your favorite text editor and set the variable MODEL_PATH to: +2. Open the file H2OModel.py with your favourite text editor and set the variable MODEL_PATH to: ```python MODEL_PATH=./SavedModel.h2o ``` - + 3. Run the python wrapping scripts, with the additional ````--base-image``` argument: ```bash docker run -v /path/to/your/model/folder:/model seldonio/core-python-wrapper:0.7 /model H2OModel 0.1 myrepo --base-image=H2OBase:1.0 ``` - + "0.1" is the version of the docker image that will be created. "myrepo" is the name of your dockerhub repository. - + 4. CD into the newly generated "build" directory and run: ```bash @@ -74,7 +74,7 @@ Here we give a step by step example in which we will train and save a [H2O model ```bash git clone https://github.com/SeldonIO/seldon-core ``` - + 2. Train and save the H2O model for bad loans prediction: ```bash @@ -89,6 +89,6 @@ Here we give a step by step example in which we will train and save a [H2O model ```bash cd ../../ docker run -v models/h2o_example:my_model seldonio/core-python-wrapper:0.7 my_model H2OModel 0.1 myrepo --base-image=H2OBase:1.0 - ``` + ``` This will create a docker image "seldonio/h2omodel:0.1", which is ready to be deployed in seldon-core. diff --git a/docs/wrappers/java.md b/docs/wrappers/java.md index 6ec2197298..3250884b67 100644 --- a/docs/wrappers/java.md +++ b/docs/wrappers/java.md @@ -3,14 +3,14 @@ In this guide, we illustrate the steps needed to wrap your own Java model in a docker image ready for deployment with Seldon Core using [source-to-image app s2i](https://github.com/openshift/source-to-image). -If you are not familar with s2i you can read [general instructions on using s2i](./s2i.md) and then follow the steps below. +If you are not familiar with s2i you can read [general instructions on using s2i](./s2i.md) and then follow the steps below. # Step 1 - Install s2i [Download and install s2i](https://github.com/openshift/source-to-image#installation) - * Prequisites for using s2i are: + * Prerequisites for using s2i are: * Docker * Git (if building from a remote git repo) @@ -76,25 +76,25 @@ default public SeldonMessage transformOutput(SeldonMessage request); default public SeldonMessage aggregate(SeldonMessageList request); ``` -Your implementing class should be created as a Spring Component so it will be managed by Spring. There is a full H2O example in ```examples/models/h2o_mojo/src/main/java/io/seldon/example/h2o/model```, whose implmentation is show below: +Your implementing class should be created as a Spring Component so it will be managed by Spring. There is a full H2O example in ```examples/models/h2o_mojo/src/main/java/io/seldon/example/h2o/model```, whose implementation is shown below: ```java @Component public class H2OModelHandler implements SeldonPredictionService { private static Logger logger = LoggerFactory.getLogger(H2OModelHandler.class.getName()); EasyPredictModelWrapper model; - + public H2OModelHandler() throws IOException { MojoReaderBackend reader = MojoReaderBackendFactory.createReaderBackend( getClass().getClassLoader().getResourceAsStream( - "model.zip"), + "model.zip"), MojoReaderBackendFactory.CachingStrategy.MEMORY); MojoModel modelMojo = ModelMojoReader.readFrom(reader); model = new EasyPredictModelWrapper(modelMojo); logger.info("Loaded model"); } - + @Override public SeldonMessage predict(SeldonMessage payload) { List rows = H2OUtils.convertSeldonMessage(payload.getData()); @@ -141,16 +141,16 @@ API_TYPE=REST SERVICE_TYPE=MODEL ``` -These values can also be provided or overriden on the command line when building the image. +These values can also be provided or overridden on the command line when building the image. # Step 3 - Build your image -Use ```s2i build``` to create your Docker image from source code. You will need Docker installed on the machine and optionally git if your source code is in a public git repo. +Use ```s2i build``` to create your Docker image from source code. You will need Docker installed on the machine and optionally git if your source code is in a public git repo. Using s2i you can build directly from a git repo or from a local source folder. See the [s2i docs](https://github.com/openshift/source-to-image/blob/master/docs/cli.md#s2i-build) for further details. The general format is: ```bash s2i build seldonio/seldon-core-s2i-java-build:0.1 --runtime-image seldonio/seldon-core-s2i-java-runtime:0.1 -s2i build seldonio/seldon-core-s2i-java-build:0.1 --runtime-image seldonio/seldon-core-s2i-java-runtime:0.1 +s2i build seldonio/seldon-core-s2i-java-build:0.1 --runtime-image seldonio/seldon-core-s2i-java-runtime:0.1 ``` An example invocation using the test template model inside seldon-core: @@ -185,7 +185,7 @@ s2i build --help # Reference ## Environment Variables -The required environment variables understood by the builder image are explained below. You can provide them in the ```.s2i/enviroment``` file or on the ```s2i build``` command line. +The required environment variables understood by the builder image are explained below. You can provide them in the ```.s2i/environment``` file or on the ```s2i build``` command line. ### API_TYPE diff --git a/docs/wrappers/nodejs.md b/docs/wrappers/nodejs.md index 4eb5fe4c8f..443eaf8dac 100644 --- a/docs/wrappers/nodejs.md +++ b/docs/wrappers/nodejs.md @@ -2,13 +2,13 @@ In this guide, we illustrate the steps needed to wrap your own JS model running on a node engine in a docker image ready for deployment with Seldon Core using [source-to-image app s2i](https://github.com/openshift/source-to-image). -If you are not familar with s2i you can read [general instructions on using s2i](./s2i.md) and then follow the steps below. +If you are not familiar with s2i you can read [general instructions on using s2i](./s2i.md) and then follow the steps below. # Step 1 - Install s2i [Download and install s2i](https://github.com/openshift/source-to-image#installation) -- Prequisites for using s2i are: +- Prerequisites for using s2i are: - Docker - Git (if building from a remote git repo) @@ -22,8 +22,8 @@ s2i usage seldonio/seldon-core-s2i-r:0.1 To use our s2i builder image to package your NodeJS model you will need: -- An JS file which provides an ES5 Function object or an ES6 class for your model and that has appropriate generics for your component, i.e an `init` and a `predict` for the model. -- A package.json that contains all the dependancies and meta data for the model +- An JS file which provides an ES5 Function object or an ES6 class for your model and that has appropriate generics for your component, i.e. an `init` and a `predict` for the model. +- A package.json that contains all the dependencies and meta data for the model - .s2i/environment - model definitions used by the s2i builder to correctly wrap your model We will go into detail for each of these steps: @@ -36,7 +36,7 @@ Your source code should which provides an ES5 Function object or an ES6 class fo let MyModel = function() {}; MyModel.prototype.init = async function() { - // A mandatory init method for the class to load run-time dependancies + // A mandatory init method for the class to load run-time dependencies this.model = "My Awesome model"; }; @@ -54,7 +54,7 @@ Also the model could be an ES6 class as follows ```js class MyModel { async init() { - // A mandatory init method for the class to load run-time dependancies + // A mandatory init method for the class to load run-time dependencies this.model = "My Awesome ES6 model"; } predict(newdata, feature_names) { @@ -71,7 +71,7 @@ module.exports = MyModel; ## package.json -Populate an `package.json` with any software dependencies your code requires using an `npm init` command and save your depedancies to the file. +Populate an `package.json` with any software dependencies your code requires using an `npm init` command and save your dependencies to the file. ## .s2i/environment @@ -84,7 +84,7 @@ SERVICE_TYPE=MODEL PERSISTENCE=0 ``` -These values can also be provided or overriden on the command line when building the image. +These values can also be provided or overridden on the command line when building the image. # Step 3 - Build your image @@ -128,7 +128,7 @@ s2i build --help ## Environment Variables -The required environment variables understood by the builder image are explained below. You can provide them in the `.s2i/enviroment` file or on the `s2i build` command line. +The required environment variables understood by the builder image are explained below. You can provide them in the `.s2i/environment` file or on the `s2i build` command line. ### MODEL_NAME diff --git a/docs/wrappers/python-docker.md b/docs/wrappers/python-docker.md index 647f4c1ece..7bfd2f415b 100644 --- a/docs/wrappers/python-docker.md +++ b/docs/wrappers/python-docker.md @@ -15,50 +15,50 @@ You can use these wrappers with any model that offers a python API. Some example * [XGBoost](https://github.com/dmlc/xgboost) The global process is as follows: -* Regroup your files under a single directory and create a standard python class that will be used as an entrypoint +* Regroup your files under a single directory and create a standard python class that will be used as an entry point * Run the wrapper script that will package your model for docker * Build and publish a docker image from the generated files ## Create a model folder -The Seldon python wrappers are designed to take your model and turn it into a dockerised microservice that conforms to Seldon's internal API. +The Seldon python wrappers are designed to take your model and turn it into a dockerised microservice that conforms to Seldon's internal API. To wrap a model, there are 2 requirements: * All the files that will be used at runtime need to be put into a single directory; -* You need a file that contains a standardised python class that will serve as an entrypoint for runtime predictions. +* You need a file that contains a standardised python class that will serve as an entry point for runtime predictions. Additionally, if you are making use of specific python libraries, you need to list them in a requirements.txt file that will be used by pip to install the packages in the docker image. Here we illustrate the content of the ```keras_mnist``` model folder which can be found in [seldon-core/examples/models/](https://github.com/SeldonIO/seldon-core/tree/master/examples). -This folder contains the following 3 files: +This folder contains the following 3 files: + +1. MnistClassifier.py: This is the entry point for the model. It needs to include a python class having the same name as the file, in this case MnistClassifier, that implements a method called predict that takes as arguments a multi-dimensional numpy array (X) and a list of strings (feature_names), and returns a numpy array of predictions. -1. MnistClassifier.py: This is the entrypoint for the model. It needs to include a python class having the same name as the file, in this case MnistClassifier, that implements a method called predict that takes as arguments a multi-dimensional numpy array (X) and a list of strings (feature_names), and returns a numpy array of predictions. - ```python from keras.models import load_model - + class MnistClassifier(object): # The file is called MnistClassifier.py - + def __init__(self): """ You can load your pre-trained model in here. The instance will be created once when the docker container starts running on the cluster. """ self.model = load_model('MnistClassifier.h5') - + def predict(self,X,feature_names): - """ X is a 2-dimensional numpy array, feature_names is a list of strings. + """ X is a 2-dimensional numpy array, feature_names is a list of strings. This methods needs to return a numpy array of predictions.""" return self.model.predict(X) ``` - + 2. requirements.txt: List of the packages required by your model, that will be installed via ```pip install```. ``` - keras==2.0.6 + keras==2.0.6 h5py==2.7.0 ``` - -3. MnistClassifier.h5: This hdf file contains the saved keras model. + +3. MnistClassifier.h5: This hdf file contains the saved keras model. ## Wrap the model @@ -75,14 +75,14 @@ Let's explain each piece of this command in more details. ``` docker run seldonio/core-python-wrapper:0.7 ``` : run the core-python-wrapper container. -``` -v /path/to/model/dir:/my_model ``` : Tells docker to mount your local folder to /my_model in the container. This is used to access your files and generate the wrapped model files. +``` -v /path/to/model/dir:/my_model ``` : Tells docker to mount your local folder to /my_model in the container. This is used to access your files and generate the wrapped model files. ``` /my_model MnistClassifier 0.1 seldonio ``` : These are the command line arguments that are passed to the script. The bare minimum, as in this example, are the path where your model folder has been mounted in the container, the model name, the docker image version and the docker hub repository. For reference, here is the complete list of arguments that can be passed to the script. ``` -docker run -v /path: seldonio/core-python-wrapper:0.7 +docker run -v /path: seldonio/core-python-wrapper:0.7 @@ -98,15 +98,15 @@ docker run -v /path: seldonio/core-python-wrapper:0.7 Required: * model_path: The path to the model folder inside the container - the same as the mount you have chosen, in our above example my_model -* model_name: The name of your model class and file, as defined abobe. In our example, MnistClassifier -* image_version: The version of the docker image you will create. By default the name of the image will be the name of your model in lowercase (more on how to change this later). In our example 0.1 +* model_name: The name of your model class and file, as defined above. In our example, MnistClassifier +* image_version: The version of the docker image you will create. By default the name of the image will be the name of your model in lower-case (more on how to change this later). In our example 0.1 * docker_repo: The name of your dockerhub repository. In our example seldonio. Optional: * out-folder: The folder that will be created to contain the output files. Defaults to ./build * service-type: The type of Seldon Service API the model will use. Defaults to MODEL. Other options are ROUTER, COMBINER, TRANSFORMER, OUTPUT_TRANSFORMER * base-image: The docker image your docker container will inherit from. Defaults to python:2. -* image-name: The name of your docker image. Defaults to model_name in lowercase +* image-name: The name of your docker image. Defaults to model_name in lower-case * force: When this flag is present, the build folder will be overwritten if it already exists. The wrapping is aborted by default. * persistence: When this flag is present, the model will be made persistent, its state being saved at a regular interval on redis. * grpc: When this flag is present, the model will expose a GRPC API rather than the default REST API @@ -117,7 +117,7 @@ Note that you can access the command line help of the script by using the -h or docker run seldonio/core-python-wrapper:0.7 -h ``` -Note also that you could use the python script directly if you feel so enclined, but you would have to check out seldon-core and install some python libraries on your local machine - by using the docker image you don't have to care about these dependencies. +Note also that you could use the python script directly if you feel so inclined, but you would have to check out seldon-core and install some python libraries on your local machine - by using the docker image you don't have to care about these dependencies. ## Build and push the Docker image @@ -131,4 +131,4 @@ cd /path/to/model/dir/build ./push_image.sh ``` -And voila, the docker image for your model is now available in your docker repository, and Seldon Core can deploy it into production. +And voilà, the docker image for your model is now available in your docker repository, and Seldon Core can deploy it into production. diff --git a/docs/wrappers/python.md b/docs/wrappers/python.md index ca9b2ce71d..8672d8edc7 100644 --- a/docs/wrappers/python.md +++ b/docs/wrappers/python.md @@ -3,14 +3,14 @@ In this guide, we illustrate the steps needed to wrap your own python model in a docker image ready for deployment with Seldon Core using [source-to-image app s2i](https://github.com/openshift/source-to-image). -If you are not familar with s2i you can read [general instructions on using s2i](./s2i.md) and then follow the steps below. +If you are not familiar with s2i you can read [general instructions on using s2i](./s2i.md) and then follow the steps below. # Step 1 - Install s2i [Download and install s2i](https://github.com/openshift/source-to-image#installation) - * Prequisites for using s2i are: + * Prerequisites for using s2i are: * Docker * Git (if building from a remote git repo) @@ -39,7 +39,7 @@ class MyModel(object): """ Model template. You can load your model parameters in __init__ from a location accessible at runtime """ - + def __init__(self): """ Add any initialization parameters. These will be passed at runtime from the graph definition parameters defined in your seldondeployment kubernetes resource manifest. @@ -65,7 +65,7 @@ class MyModel(object): * Your return array should be at least 2-dimensional. ## requirements.txt -Populate a requirements.txt with any software dependencies your code requires. These will be installled via pip when creating the image. You can instead provide a setup.py if you prefer. +Populate a requirements.txt with any software dependencies your code requires. These will be installed via pip when creating the image. You can instead provide a setup.py if you prefer. ## .s2i/environment @@ -78,7 +78,7 @@ SERVICE_TYPE=MODEL PERSISTENCE=0 ``` -These values can also be provided or overriden on the command line when building the image. +These values can also be provided or overridden on the command line when building the image. # Step 3 - Build your image Use ```s2i build``` to create your Docker image from source code. You will need Docker installed on the machine and optionally git if your source code is in a public git repo. You can choose from three python builder images @@ -128,7 +128,7 @@ s2i build --help # Reference ## Environment Variables -The required environment variables understood by the builder image are explained below. You can provide them in the ```.s2i/enviroment``` file or on the ```s2i build``` command line. +The required environment variables understood by the builder image are explained below. You can provide them in the ```.s2i/environment``` file or on the ```s2i build``` command line. ### MODEL_NAME diff --git a/docs/wrappers/r.md b/docs/wrappers/r.md index 998a23ce0d..44691b7c04 100644 --- a/docs/wrappers/r.md +++ b/docs/wrappers/r.md @@ -2,13 +2,13 @@ In this guide, we illustrate the steps needed to wrap your own R model in a docker image ready for deployment with Seldon Core using [source-to-image app s2i](https://github.com/openshift/source-to-image). -If you are not familar with s2i you can read [general instructions on using s2i](./s2i.md) and then follow the steps below. +If you are not familiar with s2i you can read [general instructions on using s2i](./s2i.md) and then follow the steps below. # Step 1 - Install s2i [Download and install s2i](https://github.com/openshift/source-to-image#installation) -- Prequisites for using s2i are: +- Prerequisites for using s2i are: - Docker - Git (if building from a remote git repo) @@ -75,7 +75,7 @@ SERVICE_TYPE=MODEL PERSISTENCE=0 ``` -These values can also be provided or overriden on the command line when building the image. +These values can also be provided or overridden on the command line when building the image. # Step 3 - Build your image @@ -119,7 +119,7 @@ s2i build --help ## Environment Variables -The required environment variables understood by the builder image are explained below. You can provide them in the `.s2i/enviroment` file or on the `s2i build` command line. +The required environment variables understood by the builder image are explained below. You can provide them in the `.s2i/environment` file or on the `s2i build` command line. ### MODEL_NAME diff --git a/docs/wrappers/readme.md b/docs/wrappers/readme.md index 1f58e9bb56..dc057bd4a6 100644 --- a/docs/wrappers/readme.md +++ b/docs/wrappers/readme.md @@ -1,9 +1,9 @@ # Wrapping Your Model -To allow your component (model, router etc) to be managed by seldon-core it needs +To allow your component (model, router etc.) to be managed by seldon-core it needs 1. To be built into a Docker container -1. To expose the approripiate [service APIs over REST or gRPC](../reference/internal-api.md). +1. To expose the appropriate [service APIs over REST or gRPC](../reference/internal-api.md). To wrap your model follow the instructions for your chosen language or toolkit. diff --git a/docs/wrappers/s2i.md b/docs/wrappers/s2i.md index 55c9760aa3..686f013c88 100644 --- a/docs/wrappers/s2i.md +++ b/docs/wrappers/s2i.md @@ -19,4 +19,4 @@ At present we have s2i builder images for * [python (python2 or python3)](./python.md) : use this for Tensorflow, Keras, pyTorch or sklearn models. * [R](r.md) * [Java](java.md) - +