Skip to content

Commit

Permalink
Merge pull request #50 from stefannica/extension-registry
Browse files Browse the repository at this point in the history
Add documentation section on installer extensions and extension registry
  • Loading branch information
stefannica authored Dec 3, 2021
2 parents ba3071c + 80160d5 commit c111490
Show file tree
Hide file tree
Showing 6 changed files with 816 additions and 6 deletions.
580 changes: 580 additions & 0 deletions docs/extensions/extension-registry.md

Large diffs are not rendered by default.

221 changes: 221 additions & 0 deletions docs/extensions/installer-extensions.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,221 @@
## Installation of 3rd party tools and services with the FuseML installer

## Overview

The FuseML installer can be used for more than installing FuseML itself. It can also be used to manage the installation of third-party tools and services and their subsequent registration in [the FuseML Extension Registry](extension-registry.md), where they can be referenced and accessed from FuseML workflows.

The installer makes a clear distinction between basic mandatory components and extensions for 3rd party tools, but at the same time provides the "all-in-one" experience of installing everything in one shot. Furthermore, the installer is flexible in that it can be extended dynamically to cover more third-party tools and services that are not included in the default tool stack maintained by the FuseML team, by defining new [Installer Extensions](#installer-extensions) and grouping them under a custom [Installer Extension Repository](#installer-extension-repository).

The [default FuseML Installer Extension Repository](https://github.com/fuseml/extensions/tree/main/installer) includes a variety of AI/ML tools that can be installed through the FuseML installer. The repository is maintained by the FuseML team and is updated regularly.

## Installer Extensions

An installer extension is represented by a `description.yaml` YAML file that provides a description of the operations that are needed to install and uninstall a third-party application. The installer extensions are designed to be used with cloud-native applications that can be deployed in a Kubernetes cluster, but they can also be used with other types of infrastructures and deployment models.

The following is an example of an installer extension descriptor defined for KServe:

```yaml
name: kserve
product: kserve
version: "0.7.0"
description: |
Serverless Inferencing on Kubernetes
requires:
- knative
- cert-manager
install:
- type: manifest
location: https://github.com/kserve/kserve/releases/download/v0.7.0/kserve.yaml
waitfor:
- namespace: kserve
selector: control-plane=kserve-controller-manager
- type: kustomize
location: kustomize
waitfor:
- namespace: kserve
selector: app.kubernetes.io/component=kserve-models-web-app
uninstall:
- type: kustomize
location: kustomize
- type: manifest
location: https://github.com/kserve/kserve/releases/download/v0.7.0/kserve.yaml
services:
- id: API
resource: kserve-api
category: prediction-serving
description: kserve prediction service API
endpoints:
- url: http://kubernetes.default.svc
type: internal
- id: UI
resource: kserve-ui
category: UI
description: KServe UI
gateways:
- name: kserve-web-app
namespace: kserve
servicehost: kserve-models-web-app
port: 80
rolerules:
- apigroups:
- serving.kserve.io
resources:
- inferenceservices
verbs:
- get
- list
- create
- patch
- watch
```
The descriptor specifies a list of installation and un-installation steps, such as Kubernetes manifests and Kustomize files, that have to be executed in order to deploy the application or to subsequently remove it from a Kubernetes cluster. The other fields in the descriptor are used to describe the application, its capabilities and its permission requirements.
The extension descriptor is broken down into sections and explored piece by piece in the following paragraphs.
```yaml
name: kserve
product: kserve
version: "0.7.0"
description: |
Serverless Inferencing on Kubernetes
[...]
```

This part is self explanatory. The `name` field is the extension identifier that along with the `product`, `version` and `description` fields is used to populate the [Extension Record](extension-registry.md#extension-records) that FuseML will use to register KServe as an extension in the [FuseML Extension Registry](extension-registry.md) after installation.

```yaml
[...]
requires:
- knative
- cert-manager
[...]
```

Extensions can depend on other extensions. If a description file contains a `requires` field, the value is expected to be a list of names of other extensions that are considered requirements for the current one. The FuseML installer will take care to install all dependencies in the right order, so they do not need to be explicitly listed on the command line.

```yaml
[...]
install:
- type: manifest
location: https://github.com/kserve/kserve/releases/download/v0.7.0/kserve.yaml
waitfor:
- namespace: kserve
selector: control-plane=kserve-controller-manager
- type: kustomize
location: kustomize
waitfor:
- namespace: kserve
selector: app.kubernetes.io/component=kserve-models-web-app
uninstall:
- type: kustomize
location: kustomize
- type: manifest
location: https://github.com/kserve/kserve/releases/download/v0.7.0/kserve.yaml
[...]
```

The `install` and `uninstall` sections list the steps necessary to install, configure and uninstall the extension. KServe is installed through a combination of Kubernetes manifests and Kustomize files. The following types of installation mechanisms are currently supported:

- `helm` - helm chart
- `manifest` - plain Kubernetes manifest, to be installed using `kubectl`. All information is expected to be present in the manifest file.
- `kustomize` - Kustomize deployment. It can be a URL (i.e. one that works as an input for `kubectl -k`) or an absolute or relative path to a local directory with Kustomize files.
- `script` - manage the installation/uninstallation through shell scripts. Specific `install` and `uninstall` actions need to be provided by way of referencing specific shell scripts.

Location arguments can be configured for every type of step to point to external resources, such as helm charts, Kubernetes manifests, Kustomize directories and shell scripts:

- `location`: could be either a URL or a local path relative to the extension directory. If used together with a helm chart, `location` needs to point to tarball with the chart.
- `repo`, `chart` and `version`: specific to helm charts only. `repo` is the chart repository from which the chart with `chart` name and the `version` version should be installed. To use this combination, the `location` field must be empty.
- `values`: points to a customized `values.yaml` file used in combination with a helm chart. Just like `location`, it can be a URL or a local path.

Each step can have its own `namespace` explicitly configured. If omitted, the global `namespace` attribute is used. If this is also missing or empty, the FuseML installer will not use any namespace during the step operation.

After the instruction from an installation step is executed, it is sometimes wise to wait until a certain condition is met to make sure the installer may continue to the next step. The `waitfor` section may be used to indicate a specific condition the installer should wait for. It takes the arguments that could generally be passed to `kubectl wait` command.
The currently supported arguments are:

- `kind` (if missing, defaults to `pod`)
- `namespace`
- `condition` (defaults to `ready`)
- `timeout` (in seconds; defaults to 300)
- `selector`. If the value of `selector` is `all`, FuseML will wait for all resources of given `kind` to reach the indicated `condition`. Otherwise, the `selector` value is treated like the value for the `--selector` option for the `kubectl wait` command.

```yaml
[...]
services:
- id: API
resource: kserve-api
category: prediction-serving
description: kserve prediction service API
endpoints:
- url: http://kubernetes.default.svc
type: internal
- id: UI
resource: kserve-ui
category: UI
description: KServe UI
[...]
```

The `services` section provides information that is reflected in the generated Extension Descriptor that FuseML will use to register the extension in the [FuseML Extension Registry](extension-registry.md), more specifically in the `services` field of the Extension Record. For more information about the fields that can be configured in the services section, see [Extension Descriptor](extension-registry.md#extension-records).

!!! note

The `services` field should only be configured for extensions that expose APIs that need to be accessed from the FuseML workflows. Extensions that are not meant to interact with FuseML workflows (e.g. those that are only used as functional dependencies for other extensions) do not need to have this field filled in and will be ignored by FuseML in relation with workflows.

```yaml
[...]
gateways:
- name: kserve-web-app
namespace: kserve
servicehost: kserve-models-web-app
port: 80
[...]
```

Some Kubernetes applications such as KServe don't include means of exposing the provided services in their official deployment manifests (e.g. Ingress, Load Balancer or Istio Gateway). When the `gateways` field is specified in the descriptor, the FuseML installer will also create one Istio gateway corresponding to each entry.

```yaml
[...]
rolerules:
- apigroups:
- serving.kserve.io
resources:
- inferenceservices
verbs:
- get
- list
- create
- patch
- watch
```
Some third party AI/ML services, like KServe, come in the form of Kubernetes operators that have associated CRD. To have access to these resources, the workflow steps need to have additional permissions granted to them. The `rolerules` section can be used to provide the list of permissions (Kubernetes roles) that need to be granted to FuseML workflow steps that need to access the extension. The syntax is the same as for the [Kubernetes Role object](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), i.e. it is expected to contain ApiGroups, Resources and Verbs values.

!!! note

All steps in a FuseML workflow are executed in the `fuseml-workloads` Kubernetes namespace and in the context of the `fuseml-workloads` service account. For 3rd party tools that are not installed using installer extensions, or that do not include `rolerules` in the extension descriptor, the admin must manually add the required permissions to the `fuseml-workloads` service account. FuseML automatically adds the permissions listed in the `rolerules` section to the mentioned service account.

For more examples of extension descriptors and how to build them, take a look at the [Installer Extension Repository maintained by the FuseML team](https://github.com/fuseml/extensions/tree/main/installer)

## Installer Extension Repository

Installer extensions have to be organized using a particular directory structure to be recognized by the FuseML installer. A FuseML installer extension repository is a directory (local or remote) containing description files of extensions. Each extension has its own subdirectory that matches the extension name. Mandatory component under each extension subdirectory is the `description.yaml` file.

Example directory structure:

```
extensions
- mlflow
- description.yaml
- values.yaml
- knative
- description.yaml
- install.sh
- uninstall.sh
```

The FuseML installer defaults to using the [Installer Extension Repository maintained by the FuseML team](https://github.com/fuseml/extensions/tree/main/installer). To point it to a different location, the optional `--extension-repository` command line argument can be used.




7 changes: 6 additions & 1 deletion docs/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,12 @@ Well, it depends on what you would you like to do:

- if you want to find out more about this project and the problems it aims to solve, proceed to the [About](about.md) section.
- if you are looking to learn about FuseML capabilities, we suggest to take the [Quick Start](quickstart.md).
- if you want to learn more about FuseML workflows and available workflow extensions, consult the [Workflows](workflows/workflows.md) section.
- if you want to learn more about FuseML's core concepts, use one of the following resources:

- the [Workflows](workflows/workflows.md) section covers FuseML workflows and available workflow extensions
- the [Extension Registry](extensions/extension-registry.md) section describes in more detail how FuseML integrates with 3rd party AI/ML services
- the [Installer Extensions](extensions/installer-extensions.md) section details how FuseML can be used to deploy and manage entire AI/ML tool stacks constructed out of 3rd party AI/ML tools

- if you are evaluating becoming a contributor to this project, go straight to [Contributing](CONTRIBUTING.md) section.

## Demo video
Expand Down
2 changes: 1 addition & 1 deletion docs/quickstart.md
Original file line number Diff line number Diff line change
Expand Up @@ -106,4 +106,4 @@ kubectl get pods -n tekton-pipelines -o wide
kubectl get pods -n fuseml-core -o wide
```

If everything is in running or completed status, you are good to go. Continue on to the [tutorial](tutorials/kserve-basic.md) section and start to have fun with FuseML.
If everything is in running or completed status, you are good to go. Continue with one of the available tutorials, such as the [MLFlow and KServe basic example](tutorials/kserve-basic.md) and start to have fun with FuseML.
9 changes: 5 additions & 4 deletions docs/tutorials/openvino-extensions.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,19 +21,20 @@ The FuseML installer can be tasked with installing more than just the FuseML cor

With FuseML Installer Extensions, users can build installation shortcuts to quickly deploy their own AI/ML tool stack, or reuse one or more of the AI/ML tools already featured in the default [FuseML Installer Extension Repository](https://github.com/fuseml/extensions/tree/main/installer), including but not limited to: MLFlow, KServe and Seldon Core.

The [Installation of ML Extensions](https://github.com/fuseml/fuseml/blob/main/docs/blueprints/001-installation-of-extensions.md) blueprint has detailed information about this feature and how it can be used to extend the installer to cover additional AI/ML tools and services.

The [Installer Extensions](../extensions/installer-extensions.md) section contains detailed information about this extensibility feature and how it can be used to extend the installer to cover additional AI/ML tools and services.
### FuseML Extension Registry

The FuseML Extension Registry is basically a database storing information about external AI/ML services and APIs that can be consumed in FuseML workflows. Specifically, each entry in the Extension Registry represents a particular instance of an external AI/ML service or API, and contains information about how it can be accessed (e.g. URLs, endpoints, client configuration and credentials) as well as what specialized roles it can play in the MLOps reference architecture (e.g. data store, model store, prediction platform, experiment tracking, distributed model training etc.).

Registering AI/ML services and APIs with the FuseML Extension Registry allows them to be discovered, accessed and consumed in FuseML workflows. This approach decouples FuseML workflows from the actual back-ends used to execute individual steps and enables users to configure MLOps workflows that are portable and reusable. The Extension Registry API is flexible enough to allow FuseML admins to register any 3rd party AI/ML tool. In addition, [FuseML Installer Extensions](#fuseml-installer-extensions) can be used not only to install AI/ML tools, but also to automatically register them with the FuseML Extension Registry.

The [Extension Registry](https://github.com/fuseml/fuseml/blob/main/docs/blueprints/003-extension-registry.md) blueprint covers detailed information about this extensibility mechanism.
The [Extension Registry](../extensions/extension-registry.md) section covers detailed information about this extensibility mechanism.

### FuseML Workflows

FuseML workflows are automation processes built out of individual, reusable steps, connected together to form a pipeline. Each step is represented by a container image that implements a particular function in the MLOps lifecycle. Workflow steps can also be thought of as integration mechanisms, especially if they connect to 3rd party services and/or act as adapters for 3rd party APIs. FuseML already features [a collection of workflow step container images](https://github.com/fuseml/extensions/tree/main/images) that implement a variety of ML functions, such as training and serving ML models.
FuseML workflows are automation processes built out of individual, reusable steps, connected together to form a pipeline. Each step is represented by a container image that implements a particular function in the MLOps lifecycle. Workflow steps can also be thought of as integration mechanisms, especially if they connect to 3rd party services and/or act as adapters for 3rd party APIs. FuseML already features [a collection of workflow step container images](https://github.com/fuseml/extensions/tree/main/images) that implement a variety of ML functions, such as training and serving ML models.

The [FuseML Workflows](../workflows/workflows.md) section covers detailed information about workflows and workflow extensions.

## OpenVINO Overview

Expand Down
3 changes: 3 additions & 0 deletions mkdocs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,9 @@ nav:
- Seldon Core predictor workflow extension: workflows/seldon-core-predictor.md
- OpenVINO Model Server predictor workflow extension: workflows/ovms-predictor.md
- OpenVINO Model Server converter workflow extension: workflows/ovms-converter.md
- Extensions:
- FuseML extension registry: extensions/extension-registry.md
- FuseML installer extensions: extensions/installer-extensions.md
- Architecture: architecture.md
- API Reference: api.md
- CLI Reference: cli.md
Expand Down

0 comments on commit c111490

Please sign in to comment.