Skip to content

Latest commit

 

History

History
89 lines (54 loc) · 6.38 KB

5.application_scopes.md

File metadata and controls

89 lines (54 loc) · 6.38 KB

5. Application Scopes

Target Role: Application Operator

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.

Categories of application scope

There are three kinds of application scope types:

  • Core application scope types: Core application scope types define grouping constructs for basic runtime behavior. They have the following characteristics:

    • Core application scope types MUST be in the core.oam.dev namespace.
    • Core application scope types MUST all be supported by any implementation of the specification. They may be implemented by any available feature in the platform, but they MUST be implemented according to the specification of each core application scope type.
    • Instances of Components referring to core WorkloadDefinition MUST be deployed into an instance of each core application scope type.
    • Runtimes MUST provide a default "root" application scope instance for each core application scope type.
    • Runtimes MUST deploy each component instances into default "root" application scope instances when an application configuration does not otherwise specify an application scope for a component instance.

  • Standard application scope types: Standard application scope types MUST be defined in standard.oam.dev group. These application scopes provide operational functionality that is commonly used by application operators and implemented by most runtimes. Runtimes are RECOMMENDED to use the standard application scope definitions as defined in this specification when providing equivalent operational functionality to those listed in the standard application scope definitions. In other words, if a runtime is implementing application scope with behavior foo and a standard application scope definition for behavior foo exists, the runtime SHOULD use the standard foo application scope definition. Application operators that intend to maximize portability of their applications should use these application scope definitions when available. Although this does not guarantee portability of an application, it is designed to increase portability across runtimes.

  • Extended application scope types: Each runtime MAY choose to implement any number of extended application scopes.

Defining an application scope

This section is normative because application scopes are an inspectable (and possibly shareable) part of the system. All scopes MUST be representable in the following format.

Application scopes are defined with schematics like components and traits.

Top-Level Attributes

These attributes provide top-level information about the scope 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 ScopeDefinition.
metadata Metadata Y Information about the scope.
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 Y 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 Index of the scope definition.

DefinitionRef

See DefinitionRef.

Standard application scopes

The following standard scopes are defined in the OAM specification.

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.

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.

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