| Info |
|---|
This page describes the Architecture and Design used for the Tosca Defined Control Loop PoCs executed in the Guilin and Honolulu releases. Please see TOSCA Defined Control Loops: Architecture and Design for the Architecture and Design being used in the Istanbul release. |
| Table of Contents |
|---|
...
The idea of using control loops to automatically (or autonomously) perform network management has been the subject of much research in the Network Management research community, see this paper for some background. However, it is only with the advent of ONAP that we have a platform that supports control loops for network management. Before ONAP, Control Loops have been implemented by hard-coding components together and hard coding logic into components. ONAP has taken a step forward towards automatic implementation of Control Loops by allowing parameterization of Control Loops that work on the premise that the Control Loops use a set of analytic, policy, and control components connected together in set ways.
...
| Drawio | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
We consider Control Loops at Design Time and Run Time.
...
- Participant Registration. This capability allows participants to register and deregister with CLAMP. The post condition for an execution of this capability is that a participant is available for participation in a control loop.
- Control Loop Commissioning. This capability allows version controlled Control Loops to be taken from the Control Loop Design Time Catalogue and be placed in the Control Loop Run Time CatalogueInventory. It also allows configuration of parameters that apply to the Control Loop Type, that is parameters that will apply to all control loop instances. Further, it allows control loop types to be commissioned on participants. Data that applies to all instances of a control loop type on a participant is sent to a participant. The participant can then take whatever actions it need to do to support the control loop type in question. The post condition for an execution of this capability is that the Control Loop definition is in the Control Loop Run Time Catalogue Inventory and all participants in this control loop type are commissioned, that is they are prepared to run instances of this control loop type.
- Control Instantiation. This capability allows an instance of a control loop to be created. The control loop instance can The control loop definition is read from the Control Loop Run Time Catalogue Inventory and values are assigned to the parameters defined for the control loop in the same manner as the existing CLAMP client does. A control loop that has been created but has not yet been sent to participants is in state UNINITIALIZED. The control loop instance is created by instantiating parameters can be revised and updated as often as the user requires. Once the user is happy with the parameters, the control loop instance is sent to participants and the control loop instance parts in elements on each participant by sending each participant its are started by participants using the control loop metadata. Once the control loop is instantiated on each participant, the Control Loop instance is marked set as instantiated being in state PASSIVE in the Control Loop Run Time CatalogueInventory. The user can now order the participants to change the state of the control loop to state RUNNING. Each participant begins accepting and processing control loop events and the control loop is set to state RUNNING in the control loop inventory. The post condition for an execution of this capability is that the Control Loop instance is running on participants and is processing events.
- Control Loop Monitoring. This capability allows control loops to be monitored. Users can check the status of a control loop instances and the status of each participant in a control loop instance. Control loop participants report their overall status and domain status periodically to CLAMP. Clamp aggregates these status reports into an aggregated control loop instance status record, which is available for monitoring. The post condition for an execution of this capability is that control loop instances are being monitored.
Once a control loop definition has been commissioned, instances of the control loop can be created, updated, and deleted. The system manages the lifecycle of control loops following the state transition diagram below.
| Drawio | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
1: Overall Architecture
The diagram below shows an overview of the architecture of TOSCA based Control Loop management.
...
Composed Control Loops are commissioned on the run time part of the system, where they are stored in the run time catalogue inventory and are available for instantiation.
...
The Control Loop Runtime Management will use ONAP services for non-functional aspects such as inventory, topology and data delivery.
1.1: Class Diagrams
1.1.1 Design Time
| Drawio | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
1.1.2 Runtime
Comment
| Drawio | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
1.2: ERD
| Drawio | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 modeled, and the targeted ecosystem to has a participant client waiting for the event distributions from CLAMP via DMaaP Message Router.
2.1: Control Loop TOSCA file definition
2.1.1 Control Loop Component Definition
A Control Loop Component that can be part of a control loop, it defines the components that partake in a control loop, and are implemented at run time by participants. The control loop component definition is truly dynamic and, as long as the participant that the control loop component definition relates to understands its definition, it can be anything. However, we have designed a base control loop component attribute that's generic and that can act as a good starting point.
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
node_types:
org.onap.CL_Component:
properties:
component_name:
type: string
description: Human readable name for the component.
required: true
provider:
type: string
description: Provider of the component and of the descriptor.
required: true
component_version:
type: string
description: Software version of the component.
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 component resource, to be uploaded during commssioning 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 |
2.1.2 Loop Definition
The loop definition is implicit explicit in the node_templates within the topology_template, any node contained within is expected to be a a Control Loop node template is specified and any node tempalte specified in the Control Loop node tepolcate is part of the control loop managed by CLAMP.
...
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
topology_templatetosca_definitions_version: tosca_simple_yaml_1_3 data_types: inputsonap.datatypes.ToscaConceptIdentifier: pmderived_docker_image:from: tosca.datatypes.Root properties: type: string name: description: docker image used for instantiatingtype: thestring PMSH service. required: true operational_policy_nameversion: type: string descriptionrequired: name of the operational policy to be triggered on MR when subscription is created. true node_types: org.onap.policy.clamp.controlloop.Participant: version: 1.0.1 derived_from: tosca.nodetypes.Root requiredproperties: true outbound_topic_nameprovider: type: string description requred: Namefalse of topic used for messages to policy. org.onap.policy.clamp.controlloop.ControlLoopElement: version: 1.0.1 requiredderived_from: truetosca.nodetypes.Root feedback_topic_nameproperties: typeprovider: string descriptiontype: Namestring of topic used for feedback from policy. requred: false required: true inventory_notification_topic_name:participant_id: type: stringonap.datatypes.ToscaConceptIdentifier description: Name ofrequred: topictrue used for inventory inventory notifications. org.onap.policy.clamp.controlloop.ControlLoop: requiredversion: true1.0.1 pmshderived_resource_idfrom: tosca.nodetypes.Root typeproperties: string descriptionprovider: ID of the PMSH blueprint in the inventory. type: string required: true node_templatesrequred: false org.onap.PM_Subscription_Handler: elements: type: org.onap.CL_Component type: list properties: application_namerequired: PMSHtrue providerentry_schema: DCAE application_Versiontype: '1onap.0.1'datatypes.ToscaConceptIdentifier org.onap.policy.clamp.controlloop.DCAEMicroserviceControlLoopElement: version: 1.0.1 resource_id: { getderived_input: pmsh_resource_id }from: org.onap.policy.clamp.controlloop.ControlLoopElement properties: monitoring_policy: 'monitoring_policy dcae_blueprint_id': application_configtype: onap.datatypes.ToscaConceptIdentifier tag_versionrequred: {true get_input: pm_docker_image } org.onap.policy.clamp.controlloop.PolicyTypeControlLoopElement: version: 1.0.1 operationalderived_policy_name: { get_input: operational_policy_name }from: org.onap.policy.clamp.controlloop.ControlLoopElement properties: pmshpolicy_publishtype_topic_nameid: { get_input: outbound_topic_name } type: onap.datatypes.ToscaConceptIdentifier policy_feedback_topic_name: { get_input: feedback_topic_name } requred: true org.onap.policy.clamp.controlloop.CDSControlLoopElement: aai_notification_topic_nameversion: { get_input: inventory_notification_topic_name } |
2.1.3 Example
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
tosca_definitions_version: tosca_simple_yaml_1_3 capability_types: org.onap.EventProducer:1.0.1 derived_from: org.onap.policy.clamp.controlloop.ControlLoopElement properties: carriercds_protocolblueprint_typeid: type: stringonap.datatypes.ToscaConceptIdentifier requiredrequred: true topology_template: node_templates: constraintsorg.onap.dcae.controlloop.DCAEMicroserviceControlLoopParticipant: version: 2.3.4 - valid_values: type: org.onap.policy.clamp.controlloop.Participant - DMAAP_message_router type_version: 1.0.1 description: Participant for - SOMETHING_ELSEDCAE microservices properties: - REST provider: ONAP data_format: org.onap.policy.controlloop.MonitoringPolicyControlLoopParticipant: typeversion: string2.3.1 requiredtype: trueorg.onap.policy.clamp.controlloop.Participant type_version: 1.0.1 constraints: description: Participant for - valid_values:DCAE microservices properties: - JSON provider: ONAP org.onap.policy.controlloop.OperationalPolicyControlLoopParticipant: - YAML version: 3.2.1 - JMStype: org.onap.policy.clamp.controlloop.Participant eventtype_formatversion: 1.0.1 description: type:Participant stringfor DCAE microservices requiredproperties: true event_format_versionprovider: ONAP org.onap.ccsdk.cds.controlloop.CdsControlLoopParticipant: type: string version: 2.2.1 requiredtype: falseorg.onap.policy.clamp.controlloop.Participant configtype_keysversion: 1.0.1 description: type:Participant listfor DCAE microservices requiredproperties: false entry_schemaprovider: ONAP org.onap.domain.pmsh.PMSH_DCAEMicroservice: type version: string1.2.3 type: org.onap.policy.clamp.controlloop.DCAEMicroserviceControlLoopElement constraints: type_version: 1.0.0 - valid_valuesdescription: Control loop element for the DCAE microservice for Performance Management Subscription Handling - all valid values should beproperties: added here provider: Ericsson - if not specified, events of any config key may be generated participant_id: name: org.onap.dcae.controlloop.DCAEMicroserviceControlLoopParticipant - 'examples for config_keyversion: ves-measurement, ves-syslog, tca_handle_out,2.3.4 dcae_blueprint_id: etc.' name: version: 0.0.1org.onap.dcae.blueprints.PMSHBlueprint derived_fromversion: tosca1.capabilities0.Root0 org.onap.EventConsumer.domain.pmsh.PMSH_MonitoringPolicyControlLoopElement: properties: responding_capabilityversion: 1.2.3 type: stringorg.onap.policy.clamp.controlloop.PolicyTypeControlLoopElement requiredtype_version: false1.0.0 carrier_protocol_typedescription: Control loop element for the monitoring policy for type:Performance stringManagement Subscription Handling requiredproperties: true constraintsprovider: Ericsson - validparticipant_valuesid: - DMAAP_message_routername: org.onap.policy.controlloop.PolicyControlLoopParticipant - SOMETHING_ELSEversion: 2.3.1 policy_type_id: - REST data_format:name: onap.policies.monitoring.pm-subscription-handler typeversion: string1.0.0 org.onap.domain.pmsh.PMSH_OperationalPolicyControlLoopElement: required: true version: 1.2.3 constraintstype: org.onap.policy.clamp.controlloop.PolicyTypeControlLoopElement - valid_valuestype_version: 1.0.0 description: Control loop -element JSONfor the operational policy for Performance Management Subscription Handling - YAML properties: - JMSprovider: Ericsson participant_id: - all valid values should be added here name: org.onap.policy.controlloop.PolicyControlLoopParticipant event_format: typeversion: string2.3.1 description: 'examples for event_format: Ves_specification, LinkUp, VnfConfigured,policy_type_id: name: onap.policies.operational.pm-subscription-handler etc.' requiredversion: true1.0.0 event_format_version:org.onap.domain.pmsh.PMSH_CDS_ControlLoopElement: version: 1.2.3 type: string type: org.onap.policy.clamp.controlloop.ControlLoopElement description: 'examples for eventtype_format_version: 51.280.4, 7.30.1, etc.'0 requireddescription: falseControl loop element for CDS for Performance config_keys:Management Subscription Handling typeproperties: list requiredprovider: falseEricsson entryparticipant_schemaId: typename: stringorg.onap.ccsdk.cds.controlloop.CdsControlLoopParticipant constraintsversion: 3.2.1 - valid_valuescds_blueprint_id: name: - all valid values should be added hereorg.onap.ccsdk.cds.PMSHCdsBlueprint version: 1.0.0 org.onap.domain.pmsh.PMSHControlLoopDefinition: - if not specified, events of any config key may be generated version: 1.2.3 type: org.onap.policy.clamp.controlloop.ControlLoop type_version: 1.0.0 - 'examples for config_keydescription: ves-measurement, ves-syslog, tca_handle_out, Control loop for Performance Management Subscription Handling properties: etc.' versionprovider: 0.0.1 Ericsson derived_from: tosca.capabilities.Root node_types: org.onap.DynamicConfigelements: properties: - name: org.onap.domain.pmsh.PMSH_DCAEMicroservice application_name: type: stringversion: 1.2.3 - descriptionname: Value used to tie the config to an application ? should we beorg.onap.domain.pmsh.PMSH_MonitoringPolicyControlLoopElement version: 1.2.3 - name: using a relationship here instead?org.onap.domain.pmsh.PMSH_OperationalPolicyControlLoopElement version: 1.2.3 required: true - application_versionname: org.onap.domain.pmsh.PMSH_CDS_ControlLoopElement type: string version: 1.2.3 |
2.1.3 Example of two Control Loop instances
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
{ required"controlLoops": true[ application_provider: { type: string "name": "PMSHInstance0", required: false data_types: "version": "1.0.1", type: object "definition": { required: false schema: "name": type: object"org.onap.domain.pmsh.PMSHControlLoopDefinition", required: false "version": "1.0.0.1" derived_from: tosca.nodes.Root org.onap.APP: }, properties: application_name: "state": "UNINITIALISED", type: string description: Human readable name for the application Product"orderedState": "UNINITIALISED", "description": "PMSH control required:loop falseinstance 0", provider: "elements": [ type: string description: Provider of the application and of{ the descriptor required: true application_version: "id": "709c62b3-8918-41b9-a747-d21eb79c6c20", type: string description: Software version of the application"definition": { required: true blueprint_id: type: string"name": "org.onap.domain.pmsh.PMSH_DCAEMicroservice", description: A reference to the app blueprint required: false"version": "1.2.3" monitoring_policy: type: string }, description: A reference to the monitoring policy required: false"participantId": { requirements: - receive: capability: org.onap.EventProducer "name": "DCAEParticipant0", relationship: org.onap.PropagateEvent occurrences: - "version": "1.0.0" - UNBOUNDED - send: }, capability: org.onap.EventConsumer relationship: org.onap.PropagateEvent "state": "UNINITIALISED", occurrences: - 0.0 - UNBOUNDED"orderedState": "UNINITIALISED", version: 0.0.1 derived_from: tosca.nodes.Root org.onap.EventRelay: properties "description": "DCAE Control Loop Element for the event_format:PMSH instance 0 control loop" type: string description: 'examples for event_format: Ves_specification }, etc.' required: true event_format_version:{ type: string description: 'examples for event_format_version: 5.28.4, 7.30.1, etc.' "id": "709c62b3-8918-41b9-a747-d21eb79c6c21", required: true config_keys: "definition": { type: list required: false entry_schema:"name": "org.onap.domain.pmsh.PMSH_MonitoringPolicyControlLoopElement", type: string constraints: "version": "1.2.3" - valid_values: }, - all valid values should be added here - if not specified, events of any config key is relayed"participantId": { - 'examples for config_key: ves-measurement, ves-syslog, tca_handle_out, "name": "PolicyParticipant0", etc.' supported_carrier_protocols:"version": "1.0.0" type: map description: 'A map}, describing supported carrier protocols and translations. The tuples define what protocol combinations are supported on the producer"state": "UNINITIALISED", and consumer side: e.g. { REST"orderedState": REST"UNINITIALISED", DMAAP: REST, DMAAP: DMAAP}' required: true key_schema"description": "Monitoring Policy Control Loop Element for the PMSH instance 0 type:control stringloop" constraints: }, - valid_values: { - DMAAP_message_router - SOMETHING_ELSE "id": "709c62b3-8918-41b9-a747-d21eb79c6c22", - REST "definition": -{ all valid values should be added here entry_schema: "name": type: string"org.onap.domain.pmsh.PMSH_OperationalPolicyControlLoopElement", constraints: - valid_values: "version": "1.2.3" - DMAAP_message_router }, - SOMETHING_ELSE - REST "participantId": { - all valid values should be added here supported_data_formats"name": "PolicyParticipant0", type: map description: 'Is a map describing supported data formats and translation."version": "1.0.0" The tuples define what protocol combinations are supported}, on the producer and consumer side: e.g. { JSON: JSON, JMS"state": JSON"UNINITIALISED", YAML:YAML }' required: true key_schema"orderedState": "UNINITIALISED", type: string constraints"description": "Operational Policy Control Loop Element for the PMSH instance 0 - valid_values:control loop" - JSON }, - JMS { - YAML - etc"id": "709c62b3-8918-41b9-a747-d21eb79c6c23", - all valid values should be added here "definition": { entry_schema: type: string "name": "org.onap.domain.pmsh.PMSH_CDS_ControlLoopElement", constraints: - valid_values: "version": "1.2.3" - JSON - JMS }, - YAML "participantId": { - etc - all valid values should be added here "name": "CDSParticipant0", requirements: - receive: capability: org.onap.EventProducer relationship"version": org"1.onap0.PropagateEvent0" occurrences: - 0.0 }, - UNBOUNDED - send: "state": "UNINITIALISED", capability: org.onap.EventConsumer relationship: org.onap.PropagateEvent occurrences"orderedState": "UNINITIALISED", - 0.0 - UNBOUNDED "description": "CDS Control version: 0.0.1 derived_from: tosca.nodes.Root relationship_types: org.onap.PropagateEvent:Loop Element for the PMSH instance 0 control loop" properties: config_keys: } type: list ] description: The relationship type used on}, requirements to org.onap.EventProducer { and org.onap.EventConsumer capabilities. Filters events by specific config_keys "name": "PMSHInstance1", to be transferred by this relationship. That is, any event with a specific"version": "1.0.1", "definition": { config_key found in the list is transferred. If list is not defined or is "name": "org.onap.domain.pmsh.PMSHControlLoopDefinition", empty, events with all config_keys are transferred. "version": "1.0.0" required: false }, entry_schema: type"state": string"UNINITIALISED", version: 0.0.1 derived_from: tosca.relationships.Root topology_template: inputs: "orderedState": "UNINITIALISED", pm_subscription_topic: type: string pm_subscription_response_topic:"description": "PMSH control loop instance 1", type"elements": string[ pm_subscription_handler_blueprint_id: type: string pm_subscription_operational_policy_id:{ type: string pm_subscription_cds_blueprint_id: type"id": string"709c62b3-8918-41b9-a747-e21eb79c6c24", enable_tls: type: string node_templates: org.onap.PM_Subscription_Handler"definition": { type: org.onap.APP properties: application_"name": PM Subscription Handler "org.onap.domain.pmsh.PMSH_DCAEMicroservice", provider: Ericsson application_"version": "1.02.03" artifact_id: get_input: pm_subscription_handler_blueprint_id }, description: Is this a reference to the DCAE Cloudify Blueprint that is"participantId": { already stored(or will be stored before CL configuration & instatiation) "name": "DCAEParticipant0", in DCAE Inventory? artifact_config: "version": "1.0.0" enable_tls: get_input: enable_tls }, pmsh_publish_topic_name: get_input: pm_subscription_topic"state": "UNINITIALISED", capabilities: pm-subscription-event-publisher: "orderedState": "UNINITIALISED", properties: carrier_protocol_type: DMAAP_message_router data_format: JSON "description": "DCAE Control Loop Element for the PMSH instance 1 control loop" event_format: pm-subscription-event-format }, event_format_version: 1.0.0 { attributes: type: org.onap.EventProducer"id": "709c62b3-8918-41b9-a747-e21eb79c6c25", occurrences: "definition": -{ 0.0 - UNBOUNDED pm-subscription-event-receiver: "name": "org.onap.domain.pmsh.PMSH_MonitoringPolicyControlLoopElement", properties: carrier_protocol_type: DMAAP_message_router "version": "1.2.3" data_format: JSON }, event_format: pm-subscription-event-response-format event_format_version: 1.0.0 "participantId": { relationships: - type: tosca.relationships.DependsOn "name": "PolicyParticipant0", - description: any ideas on a better realtionship ? or is it better to "version": "1.0.0" just use the root realtionship ? }, - target: org.onap.PM_Monitoring_Policy attributes"state": "UNINITIALISED", type: org.onap.EventConsumer "orderedState": "UNINITIALISED", occurrences: - 0.0 "description": "Monitoring Policy Control -Loop UNBOUNDEDElement for the PMSH org.onap.PM_Monitoring_Policy: instance 1 control loop" type: org.onap.DynamicConfig properties: }, application_name: PM Subscription Handler { application_version: 1.0.0 provider: Ericsson data_types: "id": "709c62b3-8918-41b9-a747-e21eb79c6c26", measurementType: "definition": { type: string DN: type: string"name": "org.onap.domain.pmsh.PMSH_OperationalPolicyControlLoopElement", nfFilter: properties"version": "1.2.3" nfNames: }, type: list "participantId": { entry_schema: string modelInvariantIDs: "name": "PolicyParticipant0", type: list "version": "1.0.0" entry_schema: }, type: string modelVersionIDs"state": "UNINITIALISED", type: list "orderedState": "UNINITIALISED", entry_schema: "description": "Operational Policy Control Loop Element for the PMSH instance type:1 stringcontrol loop" measurementGroup: }, properties: { masurementTypes: type: list"id": "709c62b3-8918-41b9-a747-e21eb79c6c27", entry_schema"definition": { type: measurementType "name": "org.onap.domain.pmsh.PMSH_CDS_ControlLoopElement", managedObjectDNsBasic: type"version": list"1.2.3" entry_schema: }, type: DN schema"participantId": { subscription: subscriptionName: type: string "name": "CDSParticipant0", required: true administrativeState"version": "1.0.0" type: string }, required: true filebasedGP"state": "UNINITIALISED", type: integer required: true"orderedState": "UNINITIALISED", fileLocation: type"description": string"CDS Control Loop Element for the PMSH instance 1 control loop" required: true } nfFilter: ] type: nfFilter } ] } measurementGroups: type: list entry_schema: type: measurementGroup description: Should I be showing a dependency between PM Subscription Handler and the PM Monitoring Policy org.onap.PM_Policy: type: org.onap.APP properties: application_name: PM Subscription Operational Policy provider: Ericsson application_version: 1.0.0 artifact_id: get_input: pm_subscription_operational_policy_id artifact_config: NOT_DEFINED requirements: - receive_0: capability: pm-subscription-event-publisher node: org.onap.PM_Subscription_Handler relationship: NOT_DEFINED properties: config_keys: - topic_name: |
2.2: Modelling from TOSCA to Commissioned Data in Run Time Inventory
| Drawio | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
2.3: Modelling from TOSCA to Instance Data Run Time Inventory
2.4: Swagger REST APIs for Control Loop
ControlLoop Runtime Swagger REST APIs:
ControlLoop_Runtime_Swagger_API.yml
Participant Swagger REST APIs:
3: APIs and Sequence Diagrams
3.1: Commissioning
Ajay Deep Singh to pad out this section
This section defines Commissioning/CRUD Operations that can be performed on ControlLoops.
A Client, in this case CLAMP, can perform CRUD operations or can commission ControlLoops from DesignTime to RunTime Inventory Database.
DesignTime/RunTime Catalogue/Inventory Database stores ControlLoop definitions, CRUD operations on database supported by REST Endpoints like Get, Delete, Create allowing selection of a particular ControlLoop to be addressed, below sequence diagram will help you understand flow how a client(Clamp) application can initiate Rest call for performing different operations on Database.
API_Gateway Service is for interacting to different database DesignTime/RunTime and should be responsible for responding success or failure status on different operations.
The commissioning of ControlLoops definition from DesignTime Catalogue to RunTime Inventory Database can we achived using the commissioning Rest Endpoint, in this process when a rest request is initiated from a client(Clamp) the API_Gateway Service take cares of fetching ControlLoops metadata from DesignTime and creates in RunTime Inventory Database, Commissioning API ControlLoop Sequence diagram will help you understand the flow.
| Warning |
|---|
In future commissioning Rest Endpoint might be updated to push ControlLoops not only in RunTime Database but to the participants involved in ControlLoop. |
3.1.1: Commissioning REST API
| Code Block | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
openapi: 3.0.3 info: description: >- The ControlLoop Commissioning API allows users to search and perform CRUD action on Controlloop Tosca exported data sets. version: 1.0.0 title: Control Loop Commissioning API license: name: Apache 2.0 url: 'http://www.apache.org/licenses/LICENSE-2.0' contact: email: lego@est.tech servers: - url: '{scheme}://onap/controlloop/v2/' variables: scheme: description: 'The Data Set API get_input: pm_subscription_topic is accessible via https and http' - send_0: enum: capability: cds-rest-receive - 'https' node: org.onap.CDS - receive_1:'http' default: 'http' capabilitytags: cds-rest-response - name: Control Loop nodedescription: org.onap.CDSCommissioning API - send_1name: design-catalogue description: CRUD actions on an capability: pm-subscription-event-receiver designtime Control Loop data sets. - name: runtime-inventory node description: org.onap.PM_Subscription_Handler relationship: NOT_DEFINED CRUD actions on an runtime Control Loop data sets. paths: /design-catalogue/loops: get: propertiestags: - design-catalogue config_keys operationId: getAllLoopsUsingGET summary: Returns a list of - topic_name: all available Control Loops. responses: get_input: pm_subscription_response_topic '200': capabilitiesdescription: OK pm-subscription-response-event-publisher content: properties application/yaml: type schema: org.onap.EventProducer carrier_protocol_type: DMAAP_message_routerarray data_format: JSON items: event_format: pm-subscription-event-response-format $ref: '#/components/schemas/ControlLoop' event_format_version: 1.0.0 /design-catalogue/loop/{controlLoopId}: occurrencesget: tags: - 0.0 - design-catalogue summary: >- UNBOUNDED org.onap.PM_CDS_Blueprint: Returns a specific control type: org.onap.APPloop. propertiesdescription: >- application_name: PMThis SubscriptionGET CDSAPI Blueprintreturns a specific control loop. provider: Ericsson operationId: getLoopByIdUsingGET application_versionparameters: 1.0.0 - artifact_idname: controlLoopId get_inputin: pm_subscription_cds_blueprint_idpath capabilities: description: 'Id of the cds-rest-receive:control loop.' propertiesrequired: true typeexample: "org.onap.EventConsumerPM_CDS_Blueprint" protocol_typeschema: REST data_formattype: JSONstring responses: event_format: cds_action_format '200': event_format_versiondescription: 1.0.0OK content: responding_capability: cds-rest-response occurrencesapplication/yaml: - 0.0 schema: - UNBOUNDED cds-rest-response$ref: '#/components/schemas/ControlLoop' propertiesdelete: tags: type: org.onap.EventProducer - design-catalogue summary: Delete protocol_type: RESTa specific Control Loop by ID. operationId: deleteLoopByIdUsingDELETE parameters: - data_format: JSON name: controlLoopId in: path event_format: cds_action_response_format description: Identity for the control loop event_format_versionrequired: 1.0.0true occurrencesstyle: simple -schema: 0.0 org.onap.controlloop0: type: org.onap.APPstring propertiesresponses: application_name'200': Test Control Loop providerdescription: EricssonOK application_version'404': 1.0.0 statusdescription: NOT_DEPLOYEDControl Loop not present |
2.2: Modelling from TOSCA to Commissioned Data in Run Time Catalogue
| Drawio | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
2.3: Modelling from TOSCA to Instance Data Run Time Catalogue
3: APIs and Sequence Diagrams
3.1: Commissioning
Ajay Deep Singh to pad out this section
This section defines Commissioning/CRUD Operations that can be performed on ControlLoops.
A Client, in this case CLAMP, can perform CRUD operations or can commission ControlLoops from DesignTime to RunTime Catalogue Database.
DesignTime/RunTime Catalogue Database stores ControlLoop definitions, CRUD operations on database supported by REST Endpoints like Get, Delete, Create allowing selection of a particular ControlLoop to be addressed, below sequence diagram will help you understand flow how a client(Clamp) application can initiate Rest call for performing different operations on Database.
API_Gateway Service is for interacting to different database DesignTime/RunTime and should be responsible for responding success or failure status on different operations.
The commissioning of ControlLoops definition from DesignTime to RunTime Catalogue Database can we achived using the commissioning Rest Endpoint, in this process when a rest request is initiated from a client(Clamp) the API_Gateway Service take cares of fetching ControlLoops metadata from DesignTime and creates in RunTime Catalogue Database, Commissioning API ControlLoop Sequence diagram will help you understand the flow.
| Warning |
|---|
In future commissioning Rest Endpoint might be updated to push ControlLoops not only in RunTime Database but to the participants involved in ControlLoop. |
3.1.1: Commissioning REST API
| Code Block | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
openapi: 3.0.3 info: description: >- The ControlLoop Commissioning API allows users to search and perform CRUD action on Controlloop Tosca exported data sets. version: 1.0.0 title: Control Loop Commissioning API license: name: Apache 2.0 url: 'http://www.apache.org/licenses/LICENSE-2.0' contact: email: lego@est.tech servers: - url: '{scheme}://onap/controlloop/v2/' variables: scheme: post: tags: - design-catalogue summary: >- Accepts a Tosca Service Template representing a Control Loop. description: >- This API Create a Control Loop. operationId: createLoopWithIDUsingPOST parameters: - name: controlLoopId in: path description: Identity for the control loop required: true style: simple schema: type: string responses: '200': description: OK '409': description: Control Loop already exist. descriptionput: 'The Data Set API is accessible viatags: https and http' - design-catalogue enum: summary: Updates a Control Loop. - 'https' operationId: updateLoopWithIDUsingPUT - 'http'parameters: default: 'http' tags- name: controlLoopId - name: Control Loop descriptionin: Commissioningpath API - name: design-catalogue description: CRUDIdentity actionsfor onthe ancontrol designtime Controlloop Loop data sets. - name: runtime-catalogue descriptionrequired: CRUD actionstrue on an runtime Control Loop data sets. paths: /design-catalogue/loopsstyle: simple get: tagsschema: - design-catalogue type: string operationId: getAllLoopsUsingGET responses: summary: Returns a list of'200': all available Control Loops. responsesdescription: OK '200404': description: OKControl Loop not found content: /runtime-inventory/commission: application/yamlpost: tags: schema: - runtime-inventory summary: >- type: array Commissions Tosca Service Template in RunTime Inventory. itemsdescription: >- This API commissions Tosca Service Template in RunTime $ref: '#/components/schemas/ControlLoop' Inventory DB. operationId: commissionLoopWithPOST responses: '200': description: OK '404': description: No matching record found for the /design-cataloguegiven criteria. /runtime-inventory/loop/{controlLoopId}: get: tags: - designruntime-catalogueinventory summary: >- Returns a specific control loop. description: >- This GET API returns a specific control loop. operationId: getLoopByIdUsingGETgetLoopByIdUsing parameters: - name: controlLoopId in: path description: 'Id of the control loop.' required: true example: "org.onap.PM_CDS_Blueprint" schema: type: string responses: '200': description: OK content: application/yaml: schema: $reftype: '#/components/schemas/ControlLoop'array delete: tags: items: - design-catalogue summary: Delete a specific Control Loop by ID.$ref: '#/components/schemas/ControlLoop' delete: tags: - runtime-inventory summary: Delete a specific Control Loop by ID. operationId: deleteLoopByIdUsingDELETEdeleteLoopByIdUsing parameters: - name: controlLoopId in: path description: Identity for the control loop required: true style: simple schema: type: string responses: '200': description: OK '404': description: Control Loop not present post: tags: - designruntime-catalogueinventory summary: >- Accepts a Tosca Service Template representing a Control Loop. description: >- This API Create a Control Loop. operationId: createLoopWithIDUsingPOSTcreateLoopWithIDUsing parameters: - name: controlLoopId in: path description: Identity for the control loop required: true style: simple schema: type: string responses: '200': description: OK '409': description: Control Loop already exist. put: tags: - designruntime-catalogueinventory summary: Updates a Control Loop. operationId: updateLoopWithIDUsingPUTupdateLoopWithIDUsing parameters: - name: controlLoopId in: path description: Identity for the control loop required: true style: simple schema: type: string responses: '200': description: OK '404': description: Control Loop not found components: /runtime-catalogue/commissionschemas: postControlLoop: tagstitle: ControlLoop type: -object runtime-catalogue summaryproperties: >- id: Commissions Tosca Service Template in RunTime Catalogue. descriptiontype: >-string ThisControlLoop: API commissions Tosca Service Template in RunTime Catalogue DB. operationIdtype: commissionLoopWithPOSTstring responses: '200': description: OK '404': description: No matching record found for the given criteria. /runtime-catalogue/loop/{controlLoopId}: get: tags: - runtime-catalogue summary: >- Returns a specific control loop. description: >- This GET API returns a specific control loop. operationId: getLoopByIdUsing parameters: - name: controlLoopId in: path description: 'Id of the control loop.' required: true example: "org.onap.PM_CDS_Blueprint" schema: type: string responses: '200': description: OK |
3.1.2: Commissioning Sequence Diagrams
GET, DELETE, CREATE API ControlLoop Sequence Diagram
Commission API ControlLoop Sequence Diagram
3.2: Instantiation
Robertas Rimkus to pad out this section
This section refers to Instantiation of a Commissioned control loop. A client, in this case CLAMP (potentially DCAEMOD, etc in the future) will render the commissioned control loops allowing selection of a particular control loop to be instantiated. User will then provide the configurations needed to instantiate the selected control loop which will be sent onto the CL_Instance_Control Service. The service will then distribute the configurations to DMaaP topic. Participants (agents) will pull the event containing the config and pick out their control loop components to be instantiated and start/set up those particular components. CL_Instance_Control Service will be waiting for a response back from all participants involved in the instantiation of the control loop, in regards to the state of instantiation. In successful response case the service will store the CL Instance LCM (Life Cycle management) data into the runtime DB as well as providing a message back to the client of the successful instantiation. In failure to receive the response case, a timeout will be called, which will result in a teardown event being sent to DMaaP. The participants will then receive the event and proceed to teardown the components that were instantiated or check that they have failed to instantiate in the first place and send a Teardown ACK back to the CL_Instance_Control Service. No CL Instance LCM data will be stored and a message indicating failure to instantiate the CL along side with the error will be sent back to the client (CLAMP).
3.2.1: Instantiation REST API
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
openapi: 3.0.3 info: title: Swagger Control Loop Instantiation description: "" version: 1.0.0 servers: - url: '{scheme}://onap/controlloop/v2/' variables: scheme: description: 'The Data Set API is accessible via https and http' contentenum: application/yaml:- 'https' - 'http' schema: default: 'http' tags: - name: instantiate description: Control Loop Instantiation typepaths: array /runtime-inventory/instantiate: post: itemstags: - instantiate summary: Instantiate a commissioned $ref: '#/components/schemas/ControlLoop'control loop operationId: delete:instantiateLoop tagsrequestBody: - runtime-catalogue summary: Delete a specific Control Loop by ID. description: Control loop that is to be instantiated content: operationId: deleteLoopByIdUsing application/json: parameters: - nameschema: controlLoopId in: path $ref: '#/components/schemas/ControlLoop' descriptionrequired: Identitytrue for the control loop responses: required200: true styledescription: simpleOK schemacontent: type: string responses: application/json: '200': descriptionschema: OK '404': type: array description: Control Loop not present post: items: tags: - runtime-catalogue summary$ref: >-'#/components/schemas/ApiResponse' Accepts404: a Tosca Service Template representing a Control Loop. description: No Control Loop description:found >- 405: This API Create a Control Loop. description: Invalid operationId:input createLoopWithIDUsing /runtime-inventory/loops/instantiated: parametersget: tags: - name: controlLoopId - instantiate insummary: pathGet a list of instantiated control loops description responses: Identity for the control loop 200: required: true description: Success style content: simple schema: typeapplication/json: string responses: '200'schema: description: OK type: array '409': description: Control Loop alreadyitems: exist. put: tags$ref: '#/components/schemas/ControlLoop' - runtime-catalogue404: summary: Updates a Control Loop.description: No instantiated control loops found operationId /runtime-inventory/loops/instantiated/{loop-id}: updateLoopWithIDUsing get: parameters: tags: - name: controlLoopId- instantiate summary: Get an in:instantiated pathcontrol loop by id descriptionparameters: Identity for the control loop - name: loop-id required: true in: path styledescription: simpleID of instantiated loop to return schema: required: true schema: type: string responses: '200': description: OK '404': content: description: Control Loop not found components application/json: schema: schemas: ControlLoop: title$ref: '#/components/schemas/ControlLoop' type 404: object properties:description: Control Loop not found put: id tags: - instantiate type: string summary: Update an instantiated control loop ControlLoop parameters: - name: loop-id type: string |
3.1.2: Commissioning Sequence Diagrams
GET, DELETE, CREATE API ControlLoop Sequence Diagram
Commission API ControlLoop Sequence Diagram
3.2: Instantiation
Robertas Rimkus to pad out this section
This section refers to Instantiation of a Commissioned control loop. A client, in this case CLAMP (potentially DCAEMOD, etc in the future) will render the commissioned control loops allowing selection of a particular control loop to be instantiated. User will then provide the configurations needed to instantiate the selected control loop which will be sent onto the CL_Instance_Control Service. The service will then distribute the configurations to DMaaP topic. Participants (agents) will pull the event containing the config and pick out their control loop components to be instantiated and start/set up those particular components. CL_Instance_Control Service will be waiting for a response back from all participants involved in the instantiation of the control loop, in regards to the state of instantiation. In successful response case the service will store the CL Instance LCM (Life Cycle management) data into the runtime DB as well as providing a message back to the client of the successful instantiation. In failure to receive the response case, a timeout will be called, which will result in a teardown event being sent to DMaaP. The participants will then receive the event and proceed to teardown the components that were instantiated or check that they have failed to instantiate in the first place and send a Teardown ACK back to the CL_Instance_Control Service. No CL Instance LCM data will be stored and a message indicating failure to instantiate the CL along side with the error will be sent back to the client (CLAMP).
3.2.1: Instantiation REST API
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
openapi: 3.0.3 info: title: Swagger Control Loop Instantiation description: "" version: 1.0.0 servers: - url: '{scheme}://onap/controlloop/v2/' variables: scheme: in: path description: ID of instantiated loop required: true schema: type: string requestBody: description: Control loop to be updated content: application/json: schema: $ref: '#/components/schemas/ControlLoop' required: true description: 'The Data Set API is accessible via httpsresponses: and http' enum200: - 'https'description: OK -content: 'http' default: 'http' tags: - name: instantiate description: Control Loop Instantiation paths: application/runtime-catalogue/instantiatejson: post: tags: schema: - instantiate summary: Instantiate a commissioned control loop $ref: '#/components/schemas/ControlLoop' operationId: instantiateLoop 404: requestBody: description: Control loopLoop thatnot isfound to be instantiated contentdelete: application/json tags: - instantiate schema: summary: Delete an instantiated control loop $refparameters: '#/components/schemas/ControlLoop' - name: loop-id required: true responsesin: path 200description: ID of instantiated loop descriptionrequired: OKtrue schema: content: type: string responses: application/json200: description: OK schema: 404: typedescription: arrayControl Loop not found components: schemas: ControlLoop: items: title: ControlLoop type: object $ref: '#/components/schemas/ApiResponse'properties: 404id: descriptiontype: Nostring Control Loop found 405controlLoopTosca: descriptiontype: Invalidstring input /runtime-catalogue/loops/instantiatedApiResponse: get: type: object tags: properties: - instantiate code: summary: Get a list of instantiated control loops type: integer responses: format: int32 200: status: description: Success type: content: string |
3.2.2: Instantiation Sequence Diagrams
3.2.3: Instantiation DMaaP API
Initial Thought for an event to be sent from CL_Instance_Control onto DMaaP for Participants to consume. The event would go onto an output topic which the Participants would be polling/subscribed to
e.g url : https://{{ONAPIP}}:{{DMaaPPort}}/events/CL_INSTANCE_CONTROL_OUTPUT
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
{ "instance-id":"myCLInstance1", "action":"INSTANTIATE", "configurations":[ { "participant-id":"Participant_DCAE", application/json:"applications":[ { schema: "application-id":"example.pmsh", type"config":{ array items: } }, $ref: '#/components/schemas/ControlLoop' { 404: description: No instantiated control loops found /runtime-catalogue/loops/instantiated/{loop-id}: get: tags: "application-id":"example.dfc", - instantiate summary: Get an instantiated control loop by id"config":{ parameters: - name: loop-id } in: path} ] description: ID of instantiated}, loop to return { required: true"participant-id":"Participant_Policy", "applications":[ schema: { type: string "application-id":"example.OperationalPolicy", responses: 200"config":{ description: OK content:} } ] } application/json: schema: $ref: '#/components/schemas/ControlLoop' 404: description: Control Loop not found put: tags: - instantiate summary: Update an instantiated control loop parameters: - name: loop-id in: path description: ID of instantiated loop required: true] } |
*Preferred solution is to send TOSCA in the body. Meaning we could reuse the parsing code which is already present and provide it to the participant.
3.2.4: Instantiation Participant API
*Suggestion was to put JAVA API code in this section for the participant talking to DMaaP. TBD
3.3: Monitoring
In this case it refers to monitoring the data that the participants will provide to DMaaP. Participants will send events to DMaaP which will be pulled by the CL_Supervision_Service in to the runtime database. Monitoring service provides APIs to display the statistics data from runtime database to the Monitoring GUI. The data provided should include a reference id to the control loops that are instantiated on the participant, as well as the applications that have been instantiated as a part of that control loop for that participant. Data should also include the time that the application has started, state of it (running/terminated) and any other critical information which would help to determine the health of an instantiated control loop and its components. Idea is for the participant to provide events every certain period of time, similar to a health-check, in order to provide consistent monitoring.
3.3.1: Monitoring REST API
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
openapi: 3.0.3 info: title: Swagger Control Loop Monitoring description: "" version: 1.0.0 servers: - url: '{scheme}://onap/controlloop/v2/' variables: scheme: schemadescription: 'The Data Set API type: string requestBody: is accessible via https and http' description: Control loop to be updatedenum: content: - 'https' application/json: - 'http' schemadefault: 'http' tags: - name: monitoring description: Control Loop Monitoring paths: $ref: '#/components/schemas/ControlLoop'/runtime-inventory/monitoring: requiredpost: true tags: - monitoring responses: summary: Input monitoring data 200:into the database descriptionrequestBody: OK contentdescription: Monitoring data to be input content: application/json: schema: $ref: '#/components/schemas/ControlLoopMonitoringData' 404required: true responses: description200: Control Loop not found deletedescription: OK tags 405: - instantiate description: Invalid input get: summary: Delete an instantiated control looptags: parameters:- monitoring - namesummary: loop-idGet monitoring data for all participants in: path responses: description: ID of200: instantiated loop requireddescription: trueSuccess schema: content: type: string responses: 200application/json: description: OK schema: 404: descriptiontype: array Control Loop not found components: schemas: ControlLoop: items: title: ControlLoop type: object properties:$ref: '#/components/schemas/MonitoringData' id404: typedescription: stringNo monitoring data found /runtime-inventory/monitoring/{participant-id}: controlLoopTosca: get: tags: type: string - ApiResponse:monitoring typesummary: objectGet monitoring data for a participant properties:by participant id codeparameters: - typename: integerparticipant-id formatin: int32path statusdescription: ID of a participant type: string |
3.2.2: Instantiation Sequence Diagrams
3.2.3: Instantiation DMaaP API
Initial Thought for an event to be sent from CL_Instance_Control onto DMaaP for Participants to consume. The event would go onto an output topic which the Participants would be polling/subscribed to
e.g url : https://{{ONAPIP}}:{{DMaaPPort}}/events/CL_INSTANCE_CONTROL_OUTPUT
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
{ "instance-id":"myCLInstance1", "action":"INSTANTIATE", "configurations":[ required: true schema: { "participant-id":"Participant_DCAE",type: string "applications"responses:[ {200: "application-id":"example.pmsh",description: OK "config"content:{ } application/json: }, schema: { "application-id":"example.dfc", $ref: '#/components/schemas/MonitoringData' "config":{ 404: description: Monitoring data for the participant not found } put: }tags: ]- monitoring }, summary: {Update monitoring data for a participant by "participant-id":"Participant_Policy", id "applications"parameters:[ - name: {participant-id in: "application-id":"example.OperationalPolicy",path description: ID of "config":{a participant required: true schema: } type: string } requestBody: ] } ] } |
*Preferred solution is to send TOSCA in the body. Meaning we could reuse the parsing code which is already present and provide it to the participant.
3.2.4: Instantiation Participant API
*Suggestion was to put JAVA API code in this section for the participant talking to DMaaP. TBD
3.3: Monitoring
In this case it refers to monitoring the data that the participants will provide to DMaaP. Participants will send events to DMaaP which will be pulled by the CL_Monitoring_Service. The data provided should include a reference id to the control loops that are instantiated on the participant, as well as the applications that have been instantiated as a part of that control loop for that participant. Data should also include the time that the application has started, state of it (running/terminated) and any other critical information which would help to determine the health of an instantiated control loop and its components. Idea is for the participant to provide events every certain period of time, similar to a health-check, in order to provide consistent monitoring.
3.3.1: Monitoring REST API
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
openapi: 3.0.3 info: title: Swagger Control Loop Monitoring description: "" version: 1.0.0 servers: - url: '{scheme}://onap/controlloop/v2/' variablesdescription: Monitoring data to be updated content: application/json: schema: $ref: '#/components/schemas/MonitoringData' required: true responses: 200: description: OK content: scheme: description: 'The Data Set API is accessible via https and http'application/json: enum: schema: - 'https' -$ref: 'http#/components/schemas/MonitoringData' default404: 'http' tags: - name: monitoring description: ControlMonitoring Loopdata Monitoringfor paths:the participant /runtime-catalogue/monitoring:not found postdelete: tags: - monitoring summary: InputDelete monitoring data intofor thea databaseparticipant by participant id requestBody: parameters: description: Monitoring- data to be inputname: participant-id contentin: path application/jsondescription: ID of a participant schemarequired: true schema: $ref: '#/components/schemas/MonitoringData' requiredtype: truestring responses: 200: description: OK 405404: description: Monitoring data for the participant not found components: Invalid inputschemas: getMonitoringData: tagsproperties: participant-id: monitoring summary: Get monitoring datatype: forstring all participants responsescontrol-loops: 200 type: array description items: Success contentproperties: cl-instance-id: application/jsontype: string schemaapplications: type: array items: $refproperties: '#/components/schemas/MonitoringData' 404: descriptionapplication-id: No monitoring data found /runtime-catalogue/monitoring/{participant-id}: get: tags: type: string - monitoring summary: Get monitoring data for a participant by participant id status: parameters: - name: participant-id intype: pathstring description: ID of a participant requiredenum: true schema: type: string- INSTANTIATION_STARTED responses: 200: - INSTANTIATED_RUNNING description: OK content: - INSTANTIATED_FAILED application/json: other-data: schema: $ref: '#/components/schemas/MonitoringData' 404: description: Monitoring data for the participant not found put: tags:type: string |
3.3.2: Monitoring Sequence Diagrams
3.3.3: Monitoring DMaaP API
Participants will send an event containing monitoring data to a DMaaP topic at a set interval after participant has received an event to instantiate a control loop
e.g url: https://{{ONAPIP}}:{{DMaaPPort}}/events/CL_MONITORING_SERVICE_INPUT
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
{ "timestamp":"1605689254", "participant-id":"Participant_DCAE", "control-loops":[ { - monitoring summary: Update monitoring data for a participant by participant id parameters:"instance-id":"myCLInstance1", - name: participant-id"applications":[ { in: path description: ID of a participant"application-id":"example.pmsh", "status":"INSTANTIATION_STARTED" required: true }, schema: { type: string "application-id":"example.dfc", requestBody: description: Monitoring data to be updated"status":"INSTANTIATION_STARTED" } content: ] }, application/json: { "instance-id":"myCLInstance2", schema: "applications":[ { $ref: '#/components/schemas/MonitoringData' "application-id":"example.pmsh", required: true responses: "status":"INSTANTIATED" 200: } ] description: OK } content: application/json: schema: $ref: '#/components/schemas/MonitoringData' 404: description: Monitoring data for the participant not found delete: tags: - monitoring summary: Delete monitoring data for a participant by participant id parameters: - name: participant-id in: path description: ID of a participant required: true schema: type: string responses: 200: description: OK 404: description: Monitoring data for the participant not found components: schemas: MonitoringData: properties: participant-id: type: string control-loops: type: array items: properties: cl-instance-id: type: string applications: type: array items: properties: application-id: type: string status: type: string enum: - INSTANTIATION_STARTED - INSTANTIATED_RUNNING - INSTANTIATED_FAILED other-data: type: string |
3.3.2: Monitoring Sequence Diagrams
3.3.3: Monitoring DMaaP API
Participants will send an event containing monitoring data to a DMaaP topic at a set interval after participant has received an event to instantiate a control loop
e.g url: https://{{ONAPIP}}:{{DMaaPPort}}/events/CL_MONITORING_SERVICE_INPUT
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
{
"timestamp":"1605689254",
"participant-id":"Participant_DCAE",
"control-loops":[
{
"instance-id":"myCLInstance1",
"applications":[
{
"application-id":"example.pmsh",
"status":"INSTANTIATION_STARTED"
},
{
"application-id":"example.dfc",
"status":"INSTANTIATION_STARTED"
}
]
},
{
"instance-id":"myCLInstance2",
"applications":[
{
"application-id":"example.pmsh",
"status":"INSTANTIATED"
}
]
}
]
} |
3.3.4: Monitoring Participant API
Presume similar thinking to Instantiation Participant API
*Suggestion was to put JAVA API code in this section for the participant talking to DMaaP. TBD
3.4: Supervision
Supervision is responsible for ensuring that
- control loops are established once their initiation has been ordered
- control loops are running correctly once their initiation is completed
- control loops are correctly removed once their removal has been ordered
3.4.1: Supervision Sequence Diagrams
3.4.2: Supervision APIs to other components
4: Design
4.1: Server Side
4.1.1 Database Schema and JPA
4.1.2: TOSCA Processing
4.1.3: Instance Control
4.1.4: Execution Monitoring
4.2: Participant Side
4.2.1: Participant Agent
4.2.2: Policy Participant Agent
4.2.3: CDS Participant Agent
4.2.4: DCAE Participant Agent
4.2.5: SO Participant Agent
4.3: Client Side
4.3.1: Client SDK: Composition of Control Loop Tosca
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:
...
]
} |
3.3.4: Monitoring Participant API
Presume similar thinking to Instantiation Participant API
*Suggestion was to put JAVA API code in this section for the participant talking to DMaaP. TBD
3.4: Supervision
Supervision is responsible for ensuring that
- control loops are established once their initiation has been ordered
- control loops are running correctly once their initiation is completed
- control loops are correctly removed once their removal has been ordered
3.4.1: Supervision Sequence Diagrams
3.4.2: Supervision APIs to other components
4: Design
4.1: Server Side
4.1.1 Database Schema and JPA
4.1.2: TOSCA Processing
4.1.3: Instance Control
4.1.4: Execution Monitoring
4.2: Participant Side
Participant is a component that acts as a bridge between Runtime and components like Policy-framework, DCAE, Kubernetes cluster etc.
It listens to Dmaap to receive messages from runtime and performs operations towards control loop components.
Every participant has two parts Participant-Intermediary and a Participant-Impl.
Participant-Intermediary is a common component that listens to Dmaap and acts on the messages, participant-impl handles the logic towards
control loop element.
4.2.1: Participant Message handling
Participant handles 4 types of messages
1. Participant State Change : This message handles states of a participant. Runtime can order participant for a state change.
ParticipantState can be set to one of the following
UNKNOWN : Control Loop execution is unknown.
PASSIVE : Control Loop execution is always rejected.
SAFE : Control Loop execution proceeds, but changes to domain state or context are not carried out.
The participant returns an indication that it is running in SAFE mode together with the action it would
have performed if it was operating in ACTIVE mode.
TEST : Control Loop execution proceeds and changes to domain and state are carried out in a test environment.
The participant returns an indication that it is running in TEST mode together with the action it has performed
on the test environment
ACTIVE : Control Loop execution is executed in the live environment by the participant.
TERMINATED : Control Loop execution is terminated and not available.
2. Control Loop Update: This message creates the control loop elements and brings them from UNINITIALIZED to PASSIVE state.
ControlLoopUpdate message contains full ToscaServiceTemplate describing all components participating in a control loop.
This acts as a template for any control loop to be created according to the template.
When participant-intermediary receives this message, it triggers creation of policy-types and policies in Policy-Framework by Policy-Participant,
and deploys DCAE from DCAE-participant
3. Control Loop State change: This message is used to order a state change in control loop element.
Runtime can order one of the following ordered states.
UNINITIALIZED : The control loop or control loop element should become uninitialized on participants, it should not exist on participants.
PASSIVE : The control loop or control loop element should initialized on the participants and be passive, that is,
it is not handling control loop messages yet.
RUNNING : The control loop or control loop element should running and is executing control loops. Once any of above states are ordered, then control loop element transitions into
UNINITIALIZED : The control loop or control loop element is not initialized on participants, it does not exist on participants.
UNINITIALIZED2PASSIVE : The control loop or control loop element is changing from uninitialized to passive,
it is being initialized onto participants.
PASSIVE : The control loop or control loop element is initialized on the participants but is passive, that is, it is not
handling control loop messages yet.
PASSIVE2RUNNING : The control loop or control loop element is changing from passive to running,
the participants are preparing to execute control loops.
RUNNING : The control loop or control loop element is running and is executing control loops.
RUNNING2PASSIVE : The control loop or control loop element is completing execution of current control loops but
will not start running any more control loops and will become passive.
PASSIVE2UNINITIALIZED : The control loop or control loop element is changing from passive to uninitialized,
the control loop is being removed from participants
4. Participant Healthcheck: This message is used to learn the health status of a participant.
As a response to any of the above message participant returns a Participant Status message, holding respective message response.
Runtime receives Participant Status message and stores relevant information in database, Or performs respective actions.
4.2.2: Policy Participant Agent
Policy participant receives messages through participant-intermediary common code, and handles them by invoking REST APIs towards policy-framework.
For example, When a ControlLoopUpdate message is received by policy participant, it contains full ToscaServiceTemplate describing all components
participating in a control loop. When the control loop element state changed from UNINITIALIZED to PASSIVE, Policy-participant triggers creation
of policy-types and policies in Policy-Framework.
When the state changes from PASSIVE to UNINITIALIZED, Policy-Participant deletes the policies, policy-types by invoking REST APIs towards policy-framework.
4.2.4: DCAE Participant Agent
DCAE participant receives messages through participant-intermediary common code, and handles them by invoking CLAMP DCAE methods,
which internally work towards DCAE.
For example, When a ControlLoopUpdate message is received by DCAE participant, it contains full ToscaServiceTemplate describing all components
participating in a control loop. When the control loop element state changed from UNINITIALIZED to PASSIVE, DCAE-participant triggers deploy
of DCAE.
When the state changes from PASSIVE to UNINITIALIZED, DCAE-Participant un-deploys DCAE by invoking methods towards CLAMP.
4.2.5: Kubernetes Participant Agent
Kubernetes participant receives messages through participant-intermediary common code, and handles them by invoking Kubernetes Open API.
For example, When a ControlLoopUpdate message is received by Kubernetes participant, When the control loop element state changed from UNINITIALIZED to PASSIVE, Kubernetes-participant triggers Kubernetes Open API and passes the HELM charts towards cluster.
4.3: Client Side
4.3.1: Client SDK: Composition of Control Loop Tosca
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
4.4.2 Scalability
The system is designed to be inherently scalable. The control loop runtime server is stateless, all state is preserved in the run time inventory in the database. When the user requests a control loop operation (such as an instantiation, activation, passivation, or an ininitialization) the server broadcasts the request to participants over DMaaP and saves details of the request to the database. The server does not directly wait for responses to requests.
When a request is broadcast on DMaaP, the request is asynchronously picked up by participants of the types required for the control loop instance and those participants manage the life cycle of its control loop elements. Periodically, each participant reports back on the status of operations it has picked up for the control loop elements it controls, together with statistics on the control loop elements over DMaaP. On reception of these participant messages, the server stores this information to its database.
The server periodically runs a supervion function, which checks the status of all existing control loop instances and the status of outstanding requests. It builds a picture of the current status of each control loop instance from the reports on the elements of the control loop instances. Once the server has a full picture, it checks that the control loop instance is in the correct state as requested by the user of the system. If the control loop is not in the correct state, the supervision function can initiate actions such aas performing retries on operations or issuing alarms or notificaitons on control loop instances.
This approach makes it easy to scale control loop LCM. As control loop instance counts increase, more than one runtime server can be deployed and REST/supervision operations on control loop instances can run in parallel. The number of participants can scale because an asynchronous broadcast mechanism is used for server-participant communication and there is no direct connection or communication channel between participants and runtime servers. Participant state, control loop instance state, and control loop element state is held in the database, so any runtime server can handle operations for any participant. Because many participants of a particular type can be deployed and participant instances can load balance control loop element instances for different control loops of many types across themselves using a mechanism such as a Kubernetes cluster.
5: Goals
5.1: MVP
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
5.2: ControlLoop in Tosca LCM Istanbul Jiras
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
...