Skip to content

Latest commit

 

History

History
638 lines (483 loc) · 35.5 KB

3.component_model.md

File metadata and controls

638 lines (483 loc) · 35.5 KB

3. The Component Model

This section defines the component model.

Components describe functional units that may be instantiated as part of a larger distributed application. For example, each microservice in an application is described as a component. The description itself is not an instance of that microservice, but a declaration of the operational capabilities of that microservice. Section 6, Application Configuration describes how components are grouped together and how instances of those components are then configured.

Component Schematics

The role of a component schematic is to permit developers to declare, in infrastructure-neutral format, the operational characteristics of a discrete unit of execution.

For example, a single microservice may be modeled as a component.

Units for Time, CPU, Memory, and Disk

In places in this specification, certain units of measure are applied. This section describes those units of measure.

Timing (Intervals)

For timing, the default unit of time is seconds, represented as an integer.

CPU count

CPU count is represented as a floating point number, where 1 means one CPU, 2 means 2 CPUs, and 0.5 means half of a CPU.

The exact meaning of this unit varies from platform to platform. Implementors should consider that logical cpu is equivalent to one AWS vCPU or one Azure vCore or one GCP Core or one IBM vCPU. Fractional values are allowed. If a runtime does not support fractional units, it MUST round up (ceiling function) to the next integer value.

Memory and Disk

Memory and disk space use the notation for bytes/kilo/mega/giga/tera/peta by just using the major unit:

  • 1024 is 1024 bytes
  • 88K is 88 kilobytes
  • 5M is 5 megabytes
  • 7G is 7 gigabytes
  • 100T is 100 terabytes
  • 9999P is 9999 petabytes

If a B is appended after the unit letter, it MUST be ignored. Thus, 5M and 5MB are treated as identical. Case is unimportant. 15k and 15K MUST be treated as the same value.

Representation

All component schematics are canonically represented as JSON and can be validated using the provided JSON Schema. Because it is more amenable for human consumption, YAML is also supported, and most of the examples are given in YAML. For the sake of validation, YAML may be converted to an equivalent JSON representation before validating it against the JSON Schema.

Top-Level Attributes

The following attributes are common across all schemata defined in this document. This structure is designed to allow object type to be determined by scanning two fields (apiVersion and kind), and provide access to common fields in the metadata section. The spec section is where type-specific information is located, and in this section the spec section defines a Component.

Attribute Type Required Default Value Description
apiVersion string Y The specific version of the OAM specification in use. This version of the specification covers apiVersions in core.oam.dev/v1alpha1.
kind string Y For a component schematic, must be ComponentSchematic.
metadata Metadata Y Component metadata.
spec Spec Y A container for all remaining attributes.

Spec

The spec defines the constituent parts of a component.

Attribute Type Required Default Value Description
parameters []Parameter N The component's configuration options.
workloadType string Y A succinct, semantically meaningful descriptor of the component's runtime profile. See "Workload Types".
osType string N The OS required to host (all of) the component's containers (since containers share a kernel with the underlying host). Possible values include:
  • linux
  • windows
For extended runtimes, this is passed in unaltered. Default can be none and let the runtime decide where to place the component.
arch string N The CPU architecture required to host (all of) the component's containers (since containers share physical hardware with the underlying host). Possible values include:
  • i386
  • amd64
  • arm
  • arm64
Default can be none and let the runtime chose architecture.
containers []Container N The OCI container(s) that implement the component.
workloadSettings []WorkloadSetting N Declaration of non-container settings that should be passed to the workload runtime

All core workload types require containers and MUST return an error and cease processing if the containers section is empty. However, extended workload types may not require containers. Thus this field is marked optional.

Parameter

The Parameters section defines all of the configurable parameters for this component.

Attribute Type Required Default Value Description
name string Y The parameter's name. Must be unique per component.
description string N A description of the parameter.
type string Y The parameter's type. One of boolean, number, string, or null as defined in the JSON specification and the JSON Schema Validation spec
required boolean N false Whether a value must be provided for the parameter.
default type indicated by type field N The parameter's default value.

Parameter name fields must be Unicode letter and number characters.

Workload Types

A workload type is an indicator to the runtime as to how it should execute the given workload. In other words, it provides a single field by which the developer can indicate to the runtime how the developer intends for this component to be executed.

Workloads are named using a simple convention: GROUP/VERSION.KIND, where GROUP is a uniquely named service collection, VERSION is an API version, and KIND is a group-unique name of a service.

Examples:

  • core.oam.dev/v1alpha1.Singleton: The group is core.oam.dev, meaning it is built-in. The version indicates that this is still an alpha version (v1alpha1). The kind is Singleton. This means the core singleton runtime must be used for this component.
  • azure.com/v1.Function: The group is azure.com (which is a vendor-specific implementation, and may not be present on all runtimes). The version is v1, which marks this as stable. The kind is Function, whose runtime implementation is the Azure Functions offering.
  • streams.oam.dev/v1beta2.Kafka: The group is streams.oam.dev, a hypothetical location where certain vendor-neutral extensions may exist. Version is v1beta2, indicating that it is moving toward stability. And the kind is Kafka.
  • caching.oam.dev/v2.Redis: The group is caching.oam.dev, version is v2, and the kind is Redis. This describes an implementation of a Redis cache.

Group, Version, Kind is a convention in Kubernetes

There are two kinds of workload types:

  • Core workload types
  • Extended workload types

Core Workload Types

The core workload types MUST be in the core.oam.dev group.

The core workload types MUST all be supported according to the definitions in this section by any runtime implementation of this specification.

Core workload types are focused on several distinguishing points:

  1. Whether they are replicable. For singleton types, no replication or scaling traits may be assigned.
  2. Whether they are daemonized. For daemon types, if the workload exits, this is considered a fault, and the system must fix it. For non-daemonized types, exit is considered a success if no error is reported.
  3. Whether they have a service endpoint with a stable name for network traffic. Workload types that have a service endpoint need a virtual IP address (VIP) with a DNS name to represent the component as a whole, addressable within their network scope and can be assigned traffic routing traits.

All core workload types are container-based, and assume that an implementation is capable of executing an OCI or Docker image as a container, and are capable of working with OCI registries.

The following core workload types are defined by this specification:

Name Type Service endpoint Replicable Daemonized
Server core.oam.dev/v1alpha1.Server Yes Yes Yes
Singleton Server core.oam.dev/v1alpha1.SingletonServer Yes No Yes
Worker core.oam.dev/v1alpha1.Worker No Yes Yes
Singleton Worker core.oam.dev/v1alpha1.SingletonWorker No No Yes
Task core.oam.dev/v1alpha1.Task No Yes No
Singleton Task core.oam.dev/v1alpha1.SingletonTask No No No
Server

Workload type name: core.oam.dev/v1alpha1.Server

A Server is used for long-running, scalable workloads that have a network endpoint with a stable name to receive network traffic for the component as a whole. Common use cases include web applications and services that expose APIs. The Server workload type has the following characteristics:

  • Defines a container runtime where zero or more replicas of the same container may be run simultaneously.
  • An application operator can increase or decrease the number of component replicas by applying and configuring traits when available.
  • A Server is daemonized. A runtime MUST attempt to restart replicas that exit regardless of error code.
  • A Server has a network endpoint with an automatically assigned virtual IP address (VIP) and DNS name addressable within the network scope to which the component belongs.
Singleton Server

Workload type name: core.oam.dev/v1alpha1.SingletonServer

A Singleton Server is a special case of the Server workload type that is limited to at most one replica. The Singleton Server workload type as the following characteristics:

  • Defines a container runtime where at most one replica of the same container may be run at a time.
  • A Singleton Server is daemonized. A runtime MUST attempt to restart the singleton replica if it exits regardless of error code.
  • A Singleton Server has a network endpoint with an automatically assigned virtual IP address (VIP) and DNS name addressable within the network scope to which the component belongs.
Worker

Workload type name: core.oam.dev/v1alpha1.Worker

A worker is used for long-running, scalable workloads that do not have a service endpoint for network requests, aside from optional liveliness and readiness probe endpoints on individual replicas. Workers are typically used to pull from queues or provide other offline processing. The worker workload type has the following characteristics:

  • Defines a container runtime where zero or more replicas of the same container may be run simultaneously.
  • An application operator can increase or decrease the number of worker replicas by applying and configuring traits when available.
  • A worker is daemonized. A runtime MUST attempt to restart replicas that exit regardless of error code.
Singleton Worker

Workload type name: core.oam.dev/v1alpha1.SingletonWorker

A singleton worker is a special case of the worker workload type that is limited to at most one replica. The singleton worker workload type as the following characteristics:

  • Defines a container runtime where at most one replica of the same container may be run at a time.
  • A singleton worker is daemonized. A runtime MUST attempt to restart the singleton replica if it exits regardless of error code.
Task

Workload type name: core.oam.dev/v1alpha1.Task

A task is used to run code or a script to completion. Commonly used to run cron jobs or one-time highly parallelizable tasks that exit and free up resources upon completion. The task workload type has the following characteristics:

  • Defines a container runtime where zero or more replicas of the same container may be run simultaneously.
  • An application operator can increase or decrease the number of worker replicas by applying and configuring traits when available
  • A task is non-daemonized. A runtime MUST NOT attempt to restart replicas that exit without an error code.
Singleton Task

Workload type name: core.oam.dev/v1alpha1.SingletonTask

A singleton task is a special case of the task workload type that is limited to at most one replica. The singleton task workload type as the following characteristics:

  • Defines a container runtime where at most one replica of the same container may be run at a time.
  • A singleton task is non-daemonized. A runtime MUST NOT attempt to restart replicas that exit without an error code.

Core workload descriptions MUST include a container section in the component schematic. Implementations of the core workload types MUST NOT require that a workloadSetting list be present in the component description (though it may allow that some settings are passed that way only if their default values are sufficient for running a workload).

Extended Workload Types

Extended workload types are per runtime, meaning that each runtime may define its own extended workload types beyond this specification. In the present version of the spec, allowing user-defined extended workload types is not supported.

Extended workload types MAY use the containers section of the component schematic, or MAY omit it. Extended workload types MAY use or omit the workloadSettings list in the component schematic. The purpose of the workloadSetting list is to provide authors of extended workload types with a location for specifying the configuration of that types.

If an extended workload type is declared in a component schematic, but is not provided by the current platform, the implementation MUST return an error and discontinue the operation.

Container

This section describes the runtime configuration necessary to run a containerized workload for this component.

Attribute Type Required Default Value Description
name string Y The container's name. Must be unique per component.
image string Y A path-like or URI-like representation of the location of an OCI image. Where applicable, this MAY be prefixed with a registry address, SHOULD be suffixed with a tag.
resources Resources Y Resources required by the container.
cmd []string N Entrypoint array.
args []string N Arguments to the entrypoint. The container image's CMD is used if this is not provided.
env []Env N Environment variables for the container.
config []ConfigFile N Locations to write configuration as files accessible within the container
ports []Port N Ports exposed by the container.
livenessProbe HealthProbe N Instructions for assessing whether the container is alive.
readinessProbe HealthProbe N Instructions for assessing whether the container is in a suitable state to serve traffic.
imagePullSecret string N Key that can be used to retrieve the credentials for pulling this secret.

The details of the way that a runtime takes imagePullSecret and loads credentials is left to the OAM runtime implementation. For example, a Kubernetes implementation may treat this as a key that can be loaded from a secret. While it is not required, it is RECOMMENDED that image names be suffixed with a digest in OCI format. The digest may be used to compute the integrity of the image. example/foobar@sha256:72e996751fe42b2a0c1e6355730dc2751ccda50564fec929f76804a6365ef5ef.

The name field is required and must be 63 characters or less, beginning and ending with an alphanumeric character ([a-z0-9A-Z]) with dashes (-), underscores (_), dots (.), and alphanumerics between.

WorkloadSetting

This section describes additional configuration for a workload (settings that are not about a container runtime).

Attribute Type Required Default Value Description
name string Y The name of this workload setting
type string N string The data type passed into the value. This is used as a hint to the underlying implementation
value any N The value for this workload setting, if fromParam is not present
fromParam string N The name of the parameter from whence to fetch the setting value. Overrides value

The workloadSettings section of a component schematic is an extensible location for specifying workload-specific configuration. The core workload types do not use this section, as it is reserved for extended workloads. Its primary purpose is to hold definitions for non-containerized extended workload types, though it may be used for containerized extended workload types where applicable.

The name field is required and must be 63 characters or less, beginning and ending with an alphanumeric character ([a-z0-9A-Z]) with dashes (-), underscores (_), dots (.), and alphanumerics between.

The workloadSettings section of a component schematic is an extensible location for specifying workload-specific configuration. Its primary purpose is to hold definitions for non-containerized extended workload types, though it may be used for containerized workload types where applicable.

The available settings are listed on the workload type object. See section 7 for details.

Workload settings are passed as name/value pairs, where the type of value may be anything supported by JSON/YAML. The runtime environment MAY choose to treat workloadSettings values as opaque, merely passing them directly to an implementing service. A runtime MAY return an error if certain constraints are not met, including:

  • Missing an expected name/value pair
  • An unrecognized key/value pair
  • A malformed value
  • An incompatibility based on the provided name/value pairs
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: ext-workload-example
spec:
  workloadType: ext.example.com/v1.ExtTask
  os: linux
  workloadSettings:
  - name: threshold
    type: numeric
    value: 55
  - name: workLabel
    type: string

The above illustrates a workload type with a few configurable settings.

Resources

Resources describe compute resources attached to a runtime.

Attribute Type Required Default Value Description
cpu CPU Y Specifies the attributes of the cpu resource required for the container.
memory Memory Y Specifies the attributes of the memory resource required for the container.
gpu GPU N Specifies the attributes of the gpu resources required for the container.
volumes []Volume N Specifies the attributes of the volumes that the container uses.
extended []ExtendedResource N Implementation-specific extended resource requirements

For any resource that cannot be satisfied by the underlying platform, the platform MUST return an error and cease deployment. A resource is considered a requirement, and failure to meet that requirement means the runtime MUST NOT deploy the application. For example, if an application requests 1P of memory, and that amount of memory is not available, the application deployment must fail. Likewise, if an application requires 1 gpu, and the runtime does not provide gpus, the application deployment MUST fail.

CPU

Attribute Type Required Default Value Description
required double Y The minimum number of logical cpus required for running this container.

See the Units section above for valid values.

Memory

Attribute Type Required Default Value Description
required string Y The minimum amount of memory in MB required for running this container. The value should be a positive integer, greater than zero.

See the Units section above for valid values.

GPU

Attribute Type Required Default Value Description
required double Y The minimum number of gpus required for running this container.

See the Units section above for valid values.

Volume

Volume describes name, a location to mount the volume, along with access mode (such as read/write or read-only) and sharing policy for the mount. It also describes the underneath disk attributes needed by the volume. The format of the path is specific to the operating system of the consuming component, though implementations SHOULD provide support for UNIX-like path representations.

Attribute Type Required Default Value Description
name string Y Specifies the name used to reference the path.
mountPath string Y Specifies the actual mount path in the filesystem.
accessMode string N RW Specifies the access mode. Allowed values are RW (read/write) and RO (read-only).
sharingPolicy string N Exclusive The sharing policy for the mount, indicating if it is expected to be shared or not. Allowed values are Exclusive and Shared.
disk Disk N Specifies the attributes of the underneath disk resources required by the volume.

See the Units section above for valid values.

Example:

name: "configuration"
mountPath: /etc/config
accessMode: RO
sharingPolicy: Shared
disk:
  required: "2G"
  ephemeral: n

The above requires that a read-only volume be mounted at the path /etc/config, backed by a volume that provides at least 2G of non-ephemeral storage.

Disk

The disk specifies the attributes of the disk used by the volume. It describes information such as minimum disk size and the disk is ephemeral or not. Ephemeral disk indicates the component requires minimum disk size on the node to run it. For example, image processing component may require a larger cache on the node to run could use ephemeral disk. When ephemeral disk is set to false, it indicates external disk will be used.

Attribute Type Required Default Value Description
required string Y The minimum disk size required for running this container. The value should be a positive value, greater than zero.
ephemeral boolean N Specifies whether external disk needs to be mounted or not.

See the Units section above for valid values.

ExtendedResource

An extended resource is a declaration of a resource requirement for an implementation-specific resource. For example, OAM-compliant platforms may expose special hardware. This field allows containers to indicate that such special offerings are required in order for the containers to operate.

Attribute Type Required Default Value Description
name string Y The name of the resource, as a Group/Version/Kind
required string Y The required condition.

The name field MUST be a group/version/kind identifying the specific resource.

Example:

extended:
- name: ext.example.com/v1.MotionSensor
  required: "1"
- name: ext.example.com/v2beta4.ServoModel
  required: z141155-t100

If the named extended resource is not available for any reason, implementations MUST return an error when a component instance is created.

Env

Env describes an environment variable as a name/value pair of strings.

Attribute Type Required Default Value Description
name string Y The environment variable name. Must be unique per container.
value string N The environment variable value. If this is not supplied, fromParam must be supplied
fromParam string N The parameter whose value should be substituted into this variable as a value

The name field must be composed of valid Unicode letter and number characters, as well as _ and -.

Example:

env:
  - name: "ADMIN_USER"
    value: "admin"  # This is a literal value
  - name: "LOGO_URL"
    fromParam: "logoURL" # This will cause the value to be read from the parameter whose name is `logoURL`

If both fromParam and value are specified, fromParam MUST take precedence, even if the parameter value is an empty value. If neither is specified, the runtime MUST produce an error.

ConfigFile

ConfigFile describes a path to a file available within the container, as well as the data that will be written into that file. This provides a way to inject configuration files into a container.

Attribute Type Required Default Value Description
path string Y An absolute path within the container.
value string N The data to be written into the file at the specified path. If this is not supplied, fromParam must be supplied
fromParam string N The parameter whose value should be written into this file as a value

The path field must contain a path that abides by the pathing rules of the underlying operating system. If a relative path is given, implementations MUST assume the path is relative to the root directory of the container. Implementations MAY produce an error if using such a path would violate security measures or path layout requirements.

Example:

config:
  - path: "/etc/access/default_user.txt"
    value: "admin"  # This is a literal value
  - path: "/var/run/db-data"
    fromParam: "sourceData" # This will cause the value to be read from the parameter whose name is `sourceData`

If both fromParam and value are specified, fromParam MUST take precedence, even if the parameter value is an empty value. If neither is specified, the runtime MUST produce an error.

Port

Attribute Type Required Default Value Description
name string Y A descriptive name for the port. Must be unique per container.
containerPort integer Y The port number. Must be unique per container.
protocol string N TCP Indicates the transport layer protocol used by the server listening on the port. Valid values are TCP and UDP.

The name field must be lowercase alphabetical characters as present in the ASCII character set (0061-007A).

HealthProbe

Health Probe describes how a probing operation is to be executed as a way of determining the health of a component.

Attribute Type Required Default Value Description
exec Exec N Instructions for assessing container health by executing a command. Either this attribute or the httpGet attribute or the tcpSocket attribute MUST be specified. This attribute is mutually exclusive with both the httpGet attribute and the tcpSocket attribute.
httpGet HTTPGet N Instructions for assessing container health by executing an HTTP GET request. Either this attribute or the exec attribute or the tcpSocket attribute MUST be specified. This attribute is mutually exclusive with both the exec attribute and the tcpSocket attribute.
tcpSocket TCPSocket N Instructions for assessing container health by probing a TCP socket. Either this attribute or the exec attribute or the httpGet attribute MUST be specified. This attribute is mutually exclusive with both the exec attribute and the httpGet attribute.
initialDelaySeconds integer N 0 Number of seconds after the container is started before the first probe is initiated.
periodSeconds integer N 10 How often, in seconds, to execute the probe.
timeoutSeconds integer N 1 Number of seconds after which the probe times out.
successThreshold integer N 1 Minimum consecutive successes for the probe to be considered successful after having failed.
failureThreshold integer N 3 Number of consecutive failures required to determine the container is not alive (liveness probe) or not ready (readiness probe).

See the Units section above for valid time values.

Exec

Attribute Type Required Default Value Description
command []string Y A command to be executed inside the container to assess its health. Each space delimited token of the command is a separate array element. Commands exiting 0 are considered to be successful probes, whilst all other exit codes are considered failures.

HTTPGet

Attribute Type Required Default Value Description
path string Y The endpoint, relative to the port, to which the HTTP GET request should be directed.
port integer Y The TCP socket within the container to which the HTTP GET request should be directed.
httpHeaders []HTTPHeader N Optional HTTP headers.

HTTPHeader

Attribute Type Required Default Value Description
name string Y An HTTP header name. This must be unique per HTTP GET-based probe.
value string Y An HTTP header value.

Both name and value must abide by the HTTP/1.1 specification for valid header values

TCPSocket

Attribute Type Required Default Value Description
port integer Y The TCP socket within the container that should be probed to assess container health.

Port must be an integer value greater than 0.

Examples

This section illustrates use of the component schematic schema defined above to describe two discrete components of a Twitter bot application.

Our first component is a frontend administrative interface. End users (bot admins) authenticate using basic authentication. The interface permits end users to configure what kind of content the bot will tweet and the intervals at which it will do so.

Because this component is stateless, horizontally scalable, and exposes an endpoint, it is best described as a Server. The username, password, and address of the backend component are configurable.

apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: frontend
  annotations:
    version: v1.0.0
    description: >
      Sample component schematic that describes the administrative interface for our Twitter bot.
spec:
  workloadType: Server
  osType: linux
  parameters:
  - name: username
    description: Basic auth username for accessing the administrative interface
    type: string
    required: true
  - name: password
    description: Basic auth password for accessing the administrative interface
    type: string
    required: true
  - name: backend-address
    description: Host name or IP of the backend
    type: string
    required: true
  containers:
  - name: my-twitter-bot-frontend
    image:
      name: example/my-twitter-bot-frontend:1.0.0
      digest: sha256:6c3c624b58dbbcd3c0dd82b4c53f04194d1247c6eebdaab7c610cf7d66709b3b
    resources:
      cpu:
        required: 1.0
      memory:
        required: 100MB
    ports:
    - name: http
      value: 8080
    env:
    - name: USERNAME
      fromParam: 'username'
    - name: PASSWORD
      fromParam: 'password'
    - name: BACKEND_ADDRESS
      fromParam: 'backend-address'
    livenessProbe:
      httpGet:
        port: 8080
        path: /healthz
    readinessProbe:
      httpGet:
        port: 8080
        path: /healthz

Our second component implements both the backend for our Twitter bot's administrative interface and a background worker process that will Tweet end-user-defined content at end-user-defined intervals (defined through the administrative interface). This component also persists its end-user-defined configuration to disk as a JSON file.

This component's design prevents it from scaling horizontally so we should only have at most one instance of it running. It also has an endpoint for an administrative interface. As such, this component is best described as a SingletonServer. Connection details for the Twitter API are configurable. The component schematic also describes the file system location where the component persists end-user-defined configuration.

apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: admin-backend
  annotations:
    version: v1.0.0
    description: >
      Sample component schematic that describes the backend for our Twitter bot.
spec:
  workloadType: core.oam.dev/v1.SingletonServer
  osType: linux
  parameters:
  - name: twitter-consumer-key
    description: Twitter API consumer key
    type: string
    required: true
  - name: twitter-consumer-secret
    description: Twitter API consumer secret
    type: string
    required: true
  - name: twitter-access-token
    description: Twitter API access token
    type: string
    required: true
  - name: twitter-access-token-secret
    description: Twitter API access token secret
    type: string
    required: true
  containers:
  - name: my-twitter-bot-backend
    image:
      name: example/my-twitter-bot-backend:1.0.0
      digest: sha256:6c3c624b58dbbcd3c0dd82b4c53f04194d1247c6eebdaab7c610cf7d66709b3b
    resources:
      cpu:
        required: 1.0
      memory:
        required: 100MB
      volumes:
      - name: config
        mountPath: /var/lib/my-twitter-bot/conf
        accessMode: RW
        sharingPolicy: Exclusive
    ports:
    - name: http
      value: 8080
    env:
    - name: TWITTER_CONSUMER_KEY
      fromParam: 'twitter-consumer-key'
    - name: TWITTER_CONSUMER_SECRET
      fromParam: 'twitter-consumer-secret'
    - name: TWITTER_ACCESS_TOKEN
      fromParam: 'twitter-access-token'
    - name: TWITTER_ACCESS_TOKEN_SECRET
      fromParam: 'twitter-access-token-secret'
    livenessProbe:
      httpGet:
        port: 8080
        path: /healthz
    readinessProbe:
      httpGet:
        port: 8080
        path: /healthz

Example: Extended Workload Type

Imagine a service runtime that checks out code from a Git repository and executes it as an Azure function. This service might be used as follows:

apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: azurefunction
  annotations:
    version: v1.0.0
    description: "Extended workflow example"
spec:
  workloadType: azure.com/v1.Function
  parameters:
  - name: github-token
    description: GitHub API session key
    type: string
    required: true
  workloadSettings:
    - name: source
      value: git://git.example.com/function/myfunction.git
    - name: github_token
      fromParam: github-token
Previous Part Next Part
2. Overview and Terminology 4. Application Scopes