Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Code Block
titleEvent Message Schema
linenumberstrue
#
# 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
nameSequence Diagram Between Policy and Controller
pagePin7


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