Skip to content

Latest commit

 

History

History
134 lines (89 loc) · 5.63 KB

3.workload.md

File metadata and controls

134 lines (89 loc) · 5.63 KB

3. Workload Definition

Target Role: Infrastructure Operator

This section defines the workload definition schematics.

Workload definitions are authored by an infrastructure operator or platform builder. A workload definition defines the kind of components that an application developer can use in an application, along with the component's schema.

The purpose of workload definitions is to provide a way for an infrastructure operator or platform builder to define what components are available to application developers on a given platform. Workload definitions can define custom schemas for any type of workload. Examples include container pods, serverless functions, data stores, message queues, or any other kind of workload that an application developer needs to design a complete application.

Usually, workload definitions are provided by the OAM runtime (just as traits are) so that application developers may inspect the OAM runtime and learn what workloads are available for use.

Top-Level Attributes

The following attributes are common across all schemata defined in this document. They follow the Kubernetes specification.

Here are the attributes that provide top-level information about the workload definition.

Attribute Type Required Default Value Description
apiVersion string Y A string that identifies the version of the schema the object should have. The core types uses core.oam.dev/v1alpha2 in this version of specification
kind string Y Must be WorkloadDefinition
metadata Metadata Y Information about the workload definition.
spec Spec Y A container for the workload definition.

Metadata

The metadata section describes the workload definition. See metadata.

Spec

The specification section contains a reference to the workload definition.

Attribute Type Required Default Value Description
definitionRef DefinitionRef Y Workload schema reference.

DefinitionRef

DefinitionRef defines an index to find the workload schema.

Attribute Type Required Default Value Description
name string Y Name of the workload schema.

The workload schema definition itself MUST contain information that can be used to uniquely identify it. An OAM runtime will use that information in a Component to refer to the workload schema instead of using the name of the workload definition.

The following conventions are RECOMMENDED:

  • Use Group/Version/Kind to uniquely identify the schema.

  • name follows the format described in Group, Version, and Kind.

  • The name of the WorkloadDefinition is the same as the name to which it refers.

    For example:

    apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: schema.example.oam.dev
spec:
  definitionRef:
    name: schema.example.oam.dev

Categories of Workload

There are three categories of workloads:

Core workloads are the kind of workloads that every OAM runtime MUST implement according to spec definition.

Standard workloads are the kind of workloads that a OAM runtime MAY implement. However, the implementation MUST strictly adhere to the schematics defined in the spec.

Extended workloads are the kind of workloads that a OAM runtime is free to define.

Core Workload

A core workload schema MUST be in the core.oam.dev group. OAM implementations MUST implement all core workloads as defined in this specification.

Here is an example of a core workload definition:

apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: x.core.oam.dev
spec:
  definitionRef:
    name: x.core.oam.dev

Standard Workload

A standard workload schema MUST be in the standard.oam.dev group. OAM implementations are NOT REQUIRED to implement standard workloads. However, if an implementation implements a workload that is already defined by a standard workload, it SHOULD use the standard workload definition as defined in this specification. Here is an example of a standard workload definition.

apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: x.standard.oam.dev
spec:
  definitionRef:
    name: x.standard.oam.dev

Extended Workload

Each OAM runtime may define its own workload definition beyond this specification. Any workload definition that is not part of the core or standard group is considered an extended workload. The name and schema of extended workloads are entirely at the discretion of the OAM implementation.

Here is an example of an extended workload:

apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: foo.cache.io
spec:
  definitionRef:
    name: foo.cache.io

Core Workload definitions

The following core workloads are defined in the OAM specification.

Containerized Workload

A containerized workload is used for long-running workloads in containers. See Containerized Workload.

Previous Next
2. Overview and Terminology 4. The Component Model