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.
#
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: |
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