...
Code Block | ||||
---|---|---|---|---|
| ||||
# # In the interest of time, swagger is being used first to express the p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo} p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; min-height: 13.0px} span.s1 {font-variant-ligatures: no-common-ligatures} schema. # This should be converted to an appropriate model language when appropriate # as this is not a REST API but rather an model of Dmaap messages. # swagger: "2.0" info: description: | This is the schema for the Operational Events common format for Control Loop operations. operation_event_request: description: | This is the schema that describes Control Loop Operational Event requests that are published by the Policy Framework to ONAP Applications (eg. Controllers, Orchestrators, etc.) for performing operations in response to a Control Loop event detected by DCAE. properties: version: description: | This is the version for this Operation Event request format. type: string common: description: | This is a common header filled with information to assist with auditing and logging the event as it is processed by the various ONAP applications. required: true type: object $ref: "#/definitions/common" action: description: | This is the action that is to be performed by the ONAP Application. required: true type: string aai: description: | This identify the entity within A&AI Database in which the action is to be taken upon. required: true type: array payload: description: | An array of name/value pairs and arrays of name/value pairs that are required to assist the application during execution of the operation. required: false type: array operation_event_response: description: | This is the schema that describes Control Loop Operational Event Responses that are published by ONAP Applications (eg. Controllers, Orchestrators, etc.) back to the Policy Framework in response to a Request. properties: version: description: | This is the version for this Operation Event Schema response format. type: string common: description: | This is a common header filled with information to assist with auditing and logging the event as it is processed by the various ONAP applications. required: true type: object $ref: "#/definitions/common" status: description: | The status of the operational action requested. required: true type: object $ref: "#/definitions/response" definitions: common: timestamp: description: | UTC timestamp for when this message is sent. For auditing and logging purposes to help track the timing of Control Loop operational events. type: string required: true originator-id: description: | Unique identifier for the entity that is publishing this operational event. This is required in case there are multiple entities deployed to support scaling/resliency, the appropriate entity can direct the request/response back to the originator. type: string required: true request-id: description: | A unique ID that identifies the request for this Operation. The request should set this and all responses should copy this over exactly. type: string required: true sub-request-id: description: | A unique ID that further identifies the request for this Operation in the case of retries for a specific operation. The request should set this value and all responses should copy this over exactly. type: string required: true timeout: description: | type: string required: true response: status: description: | The response status for the operation. Upon receiving a requeset, the response should send ACCEPTED, ERROR or REJECTED. ACCEPTED the application has accepted the operation and has begun working on it. REJECTED the application has rejected the operation. Once an ACCEPTED response is published, the application must follow up with a response of SUCCESS or FAILURE on the operation. type: string values: { "ACCEPTED", "REJECTED", "SUCCESS", "FAILURE" } message: description: | For ACCEPTED and SUCCESS, this field is optional to add a mesage to. For REJECTED and FAILURE, this field must indicate a human-readable message as to why it was rejected or failed. type: string required: false |
- Identify how the AAI structure should be expressed. Especially in regards to PNF/VNF/ANF/VM ??
Flow diagram for these Events Policy to Controllers/Orchestrators
Gliffy name Sequence Diagram Between Policy and Controller pagePin 7
Example messages request/response for SUCCESS scenario
Example messages request/response for FAILURE scenario
Additional Information on the format of the DCAE Control Loop event to Policy Platform
Additional Information On How the Operational Policy Templates will log messages during Control Loop
Policy R3 Casablanca - Control Loop Operational Policy