Check subscriptions and send notifications

[TheWall89]

Quoting Marc's slides:

To update asynchronously the status of NS SOL005 -> NSLifecycleManagementNotification Three types of notifications:

• NsLcmOperationOccurrenceNotification -> Related to the OpOcc created in asynchronous operations. Inform about: NS id, OpOcc id, OpOcc status (START, RESULT), StateType (PROCESSING, COMPLETED, etc.) and affected components
• NsIdentifierCreationNotification: Informs about NS id creation
• NsIdentifierDeletionNotification: Informs about NS id deletion

Based on subscription: LccnSubscriptionRequest Proposal:

• Portal subscribes to NS id after the Instantiate Request (check with Giada).
• MSNO generates notifications based on the notifications received from the driver(s)

All site NFVO supports this? No, neither OSM or ONAP support the notification. To implement a polling system at MSNO-LO to generate the notifications.

Draft workflow:

Requirements:

• [x] Have a queue/stack of resource statuses to check if status changes. Send notification ONLY if status of the monitored resource is changed. RabbitMq/Kafka
• [x] Run a separate thread on Flask that checks subscriptions and sends notifications (re-uses driver functions to get information from NFVO)

Possible issues:

• Ability to create separate thread from Flask. Maybe we can use another process.
• Looping on the list of subscriptions can take some time, increasing the average time of notifications. Run benchmark. Possible solution: spawn more threads in parallel to check the subs.

[TheWall89]

Create a background thread/process from Flask. Some resources:

• https://stackoverflow.com/questions/36342718/starting-background-daemon-in-flask-app
• https://smirnov-am.github.io/background-jobs-with-flask/
• https://celery.readthedocs.io/en/latest/getting-started/first-steps-with-celery.html
• https://dramatiq.io/index.html

[zvfvrv]

https://apscheduler.readthedocs.io/en/stable/

[mifot]

about proposal

The main idea of our proposal is to try create a generic solution for subscription system in MSO-LO and separate MSO-LO from components responsible for checking ns instances information etc. (OSM case) or creating notification (like for ONAP proxy solution). The overview of the proposal is presented below.

That idea require to create a new path (for each NFVO) and new module. NFVO specific solution is a source of notification messages which are sent to MSO-LO using new path. Then the new module handle that messages and based on data from database and messages details make a decision to send/forward the notification to MSNO or not.

We can make a decision about sending/forwarding notification to MSNO in NFVO specific solution, but then the information about subscription have to be stored in that tools or be accessible by them (guess that not a problem for OSM, but for ONAP the information should be saved then in internal site database)

NFVO specific solution can be a celery worker (or other framework/solution) [one for each NFVO] – OSM, or in ONAP case proxy server located in French site.

For OSM you can implement your ideas using for ex celery worker.

Due to that solution we can separate MSO-LO from “dirty work” for each orchestrator. It seems to have a pretty good performance as well.

To make it more clear, below the workflow for instantiating ns instance process for ONAP is attached.

[mifot]

about Celery

We use celery worker in our proxy server for asynchronous operation. Celery require message broker like rabbitMQ or Redis. Celery worker can be separate container (one or many, with multiple processes) [for ex one for each NFVO] with one broker.

For OSM you can implement your propose like a task in celery worker. But I’m not sure how to trigger that task at the time when the container starts, but it should be possible.

[TheWall89]

Thanks @mifot for the great summary of the proposal.

I propose to add the following path to the API: POST '/nfvo/<nfvo_id>/notifications' With the following request body (inspired by SOL 005):

{
  "nsInstanceId": "string",
  "nsLcmOpOccId": "string",
  "operation": "INSTANTIATE",
  "notificationType": "NsLcmOperationOccurrenceNotification",
  "timestamp": "string",  
  "notificationStatus": "START",
  "operationState": "PROCESSING"
}

The code to handle this should be something like this in Flask:

@app.route('/nfvo/<nfvo_id>/notifications', methods=['POST'])
def post_notification(nfvo_id):
    if subscription_exists(nfvo_id, request.json):
        forward_notification_to_msno()
    else:
        pass

Of course the code in the method will be moved to a new, dedicated python module. I think this is all we need to add in the common code. Does it look correct to you?

Me and Francesco are going to review Celery and draft a solution to implement notifications in the OSM driver. Thank you very much for the clear explanation and the diagrams. Great solution !

[mifot]

I guess that the path to the API should look like: POST '/nfvo/<nfvo_id>/notifications' instead of POST '/nfvo/<nfvo_id>/ns_instances' ;)

To make sure, we are going to subscribe not only lcmOpp state changes (for instantiate and terminate ns) but also creating and deleting ns instance, right? So then some parameters in POST body will be set to 'null'?

Could you explain what the parameter "notificationStatus" means?

I checked swagger for MSO-LO and in notification message body there is also "timestamp" parameter. So because for LcmOpp there are some timpestamps, I think we should add it as well to the presented request body.

Thanks

[TheWall89]

I guess that the path to the API should look like: POST '/nfvo/<nfvo_id>/notifications' instead of POST '/nfvo/<nfvo_id>/ns_instances' ;)

Yep, sorry. Editing my comment above.

To make sure, we are going to subscribe not only lcmOpp state changes (for instantiate and terminate ns) but also creating and deleting ns instance, right? So then some parameters in POST body will be set to 'null'?

Yes. The notificationType field can get three values:

• NsIdentifierDeletionNotification
• NsIdentifierCreationNotification
• NsLcmOperationOccurrenceNotification

Could you explain what the parameter "notificationStatus" means?

From SOL005:

Indicates whether this notification reports about the start of a NS lifecycle
operation or the result of a NS lifecycle operation. Permitted values:
- START: Informs about the start of the NS LCM operation occurrence.
- RESULT: Informs about the final or intermediate result of the NS LCM operation occurrence.

I checked swagger for MSO-LO and in notification message body there is also "timestamp" parameter. So because for LcmOpp there are some timpestamps, I think we should add it as well to the presented request body.

Yes, sorry but I forgot to copy the field from SOL005. Changing my previous comment. Thanks

[TheWall89]

Note: We should also add some tests for this feature to be included in D3.7