...
| draw.io Diagram | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The The Design Time Catalogue contains the the metadata primitives for composition of control loops. As shown in the figure above, the Design time component provides a system where Control Loops can be designed and defined in metadata. This means that a Control Loop can have any arbitrary structure and the Control Loop developers can use whatever analytic, policy, or control primitives they like to implement their Control Loop. At deployment time, the user parameterises the Control Loop and deploys it. A design time catalogue is created. This catalogue contains the primitive metadata for any components that can be used to compose a Control Loop. A Control Loop SDK is used to compose a Control Loop by aggregating the metadata for the components chosen to be used in a Control Loop and by constructing the references between the components.
...
When a user wishes to instantiate a Control Loop, they set values for the parameters of the Control Loop. Once the parameterization has been carried out, the Control Loop instantiated, with the metadata and whatever other artifacts are required being passed to the participants in the Control Loop. At runtime, the Control Loop can be monitored and analysed. It can also be updated as required and can be deleted when it is on longer needed.
Performing a hot upgrade of the Control Loop at run time as well as handling an upgrade of the software in one or more of the participants in an Control Loop is a particularly challenging issue because upgrading must handle the following cases without tearing down the Control Loop:
- Upgrade and changes of the configuration data of participants
- Addition of or removal of participants in an Control Loop
- Upgrade of software in one or more participants in an Control Loop
- Maintenance of compatibility between participants when an update of more than one participant must be done together to ensure compatibility, for example, when a protocol being used by two participants to communicate is upgraded
The Control Loop Runtime Management will use ONAP services for non-functional aspects such as inventory, topology and data delivery.
The diagram below outlines the architecture of the TOSCA defined control loop management.
A TOSCA file contains the descriptor of the control loop. The entire control loop definition, including references to required artifacts, are included in the TOSCA file. The TOSCA file may be packaged in a CSAR, which also includes further artifacts that are required to deploy and instantiate a control loop.
Liam Fallon to pad out
2: Control Loop Modelling
Joseph O'Leary to pad out this section
node_templates which makes up the loop itself.
Applications can be a DCAE microservice, an operational policy, or any other application as long as it can be modelled, and the targeted ecosystem to has a participant client waiting for the event distributions from CLAMP via DMaaP MR.
2.1: Control Loop TOSCA file definition
2.1.1 Application Definition
The application definition is truly dynamic, and as long as the participant that the application relates to, it can be anything, however, we have designed a base attribute, that's generic and a can act as a good starting point.
The Control Loop Runtime Management will use ONAP services for non-functional aspects such as inventory, topology and data delivery.
2: Control Loop Modelling
Joseph O'Leary to pad out this section
node_templates which makes up the loop itself.
Applications can be a DCAE microservice, an operational policy, or any other application as long as it can be modelled, and the targeted ecosystem to has a participant client waiting for the event distributions from CLAMP via DMaaP MR.
2.1: Control Loop TOSCA file definition
2.1.1 Application Definition
The application definition is truly dynamic, and as long as the participant that the application relates to, it can be anything, however, we have designed a base attribute, that's generic and a can act as a good starting point.
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
| Code Block | ||||||||
| ||||||||
node_types:
org.onap.APP:
properties:
application_name:
type: string
description: Human readable name for the application.
required: true
provider:
type: string
description: Provider of the application and of the descriptor.
required: true
application_version:
type: string
description: Software version of the application.
required: true
resource_id:
type: string
description: >The ID of the resource,
should be provided if the resource was uploaded to the entity's inventory already.
required: false
resource_content:
type: string
description: the contents of the application resource, to be uploaded during deploy phase of loop.
required: false
monitoring_policy:
type: string
description: A reference to the monitoring policy if applicable.
required: false
version: 0.0.1
derived_from: tosca.nodes.Root |
...
4.3.2: Client User Interface
4.4 Other COnsiderations
4.4.1 Upgrade
Performing a hot upgrade of the Control Loop at run time as well as handling an upgrade of the software in one or more of the participants in an Control Loop is a particularly challenging issue because upgrading must handle the following cases without tearing down the Control Loop:
- Upgrade and changes of the configuration data of participants
- Addition of or removal of participants in an Control Loop
- Upgrade of software in one or more participants in an Control Loop
- Maintenance of compatibility between participants when an update of more than one participant must be done together to ensure compatibility, for example, when a protocol being used by two participants to communicate is upgraded
5: MVP
5.1: Goals
5.2: Limitations
...