Event Message Schema

This is the proposal for the format Model Schema for the Event Message:

Event Message Schema

#
# In the interest of time, swagger is being used first to express the 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

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