Closed TheWall89 closed 4 years ago
Create a background thread/process from Flask. Some resources:
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.
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.
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 !
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
I guess that the path to the API should look like:
POST '/nfvo/<nfvo_id>/notifications'
instead ofPOST '/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:
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
Note: We should also add some tests for this feature to be included in D3.7
Quoting Marc's slides:
Draft workflow:
Requirements:
Possible issues: