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:
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.
An application scope is represented by ScopeDefinition
entity.
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 specification. |
|
kind |
string |
Y | Must end with ScopeDefinition . |
|
metadata |
Metadata |
Y | Entity metadata. | |
spec |
Spec |
Y | A specification for scope attributes. |
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. |
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. |
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 the OAM specification.
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 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 |