Skip to content

Latest commit

 

History

History
85 lines (56 loc) · 4.58 KB

5.application_scopes.md

File metadata and controls

85 lines (56 loc) · 4.58 KB
Raw

5. Application Scopes

Application scopes are used to group components together into logical applications by providing different forms of application boundaries with common group behaviors.

Application scopes have the following general characteristics:

  • Application scopes SHOULD be used when defining behavior or metadata that is common to a group of component instances.
  • A component MAY be deployed into multiple application scopes of different types simultaneously.
  • Application scope types MAY determine whether or not components can be deployed into multiple instances of the same application scope type simultaneously.
  • Application scopes MAY be used as a connecting mechanism between groups of components and capabilities provided by infrastructure, such as networking, or external capabilities, such as identity providers.

The following diagram illustrates how components can be grouped into overlapping application scopes to create different application boundaries:

Scope diagram

This example shows two scope types with four components distributed among them.

Components A, B, and C are deployed to the same health scope. The health scope will collect aggregate health information on its constituent components that is evaluated during component upgrade operations. Query information provided by the health scope can be further used by traits or components that need to evaluate and/or perform actions based on the aggregate health of a set of components. This is a basic grouping construct for applications that provides a loose definition of dependencies between components.

Component A is isolated in its own network scope from components B, C, and D. This allows the infrastructure operator to supply different SDN settings for different groups of components, such as more restricted inbound/outbound rules on back-end components.

Defining an application scope

An application scope is represented by ScopeDefinition entity.

Top-Level Attributes

These attributes provide top-level information about the application scope.

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/v1beta1 in this version of model.
kind string Y Must end with ScopeDefinition.
metadata Metadata Y Entity metadata.
spec Spec Y A specification for scope attributes.

Spec

The spec defines the constituent parts of a scope.

Attribute Type Required Default Value Description
allowComponentOverlap bool N true Determines whether a component is allowed to be in multiple instances of this scope type simultaneously. When false, the runtime implementation MUST produce an error and stop deployment if an attempt is made to place a component into more than one instance of this scope type simultaneously.
definitionRef DefinitionRef Y Identifier to scope capability in the platform.

DefinitionRef

Attribute Type Required Default Value Description
name string N Name identifier of the scope capability. Mutually exclusive to apiVersion and kind.
apiVersion string N API version of the scope capability.
kind string N Kind of the scope capability.

Examples

apiVersion: core.oam.dev/v1beta1
kind: ScopeDefinition
metadata:
  name: healthscopes.core.oam.dev
spec:
  allowComponentOverlap: true
  definitionRef:
    name: healthscopes.core.oam.dev

The following sample scope capabilities are defined in this documentation.

Health Scope

Health scope groups components into an aggregate health group. The aggregate health of the constituent components within the group supplies information to upgrade and rollback mechanisms.

See Health Scope.

Network Scope

Network scope groups components into a network subnet boundaries and defines the general runtime networking model. Network definitions, rules, and policies are described by the infrastructure's network or SDN.

See Network Scope.

Previous Part Next Part
4. The Component Model 6. Traits