Details
-
Sub-task
-
Status: Closed
-
Medium
-
Resolution: Done
-
None
-
None
-
None
-
Beijing SO Sprint 2
Description
Existing workflows might be sufficient for HPA but should be investigated.
Task should include:
- Investigate current flows and modifications needed - interact with Multicloud team and understand interaction
- document modification needed on ONAP SO wiki, here in task and get buy-in from stakeholder (PTL, Marcus, Alex, Team) on approach
- possible patch that includes
- bpmn workflows modification
- possible groovy script modification
Update 5:
Since all this is dependent on the Heat Stack ID, it is queried from AAI (queryAAIVfModule)[1] and set in execution which is later used in the VNF Adapter create request [2].
Update 4:
- Heat Template obtained from DB queries by Heat ID in MSO VNF adapter [1].
- Input parameters for the heat templates are converted from map<string, string> to map<string, object> which gets later used in StackCreate [2].
- Heat Environment variables obtained from DB [3].
- All this is passed to OpenStack StackCreate [4].
Question: Since the Heat template and the Heat environment is obtained from DB, should the Flavor-VM-ID Homing solution obtained from OOF be updated in the Catalog with the correct format so that the new flavor ID gets fetched in VNF adaptor?
Update 3:
- Seem like in vCPEResCus workflow which calls DoCreateVfModule, heat stack ID is first seen here [1] . This seems to be generated inside VNF adaptor based on our request which we pass to VNF adaptor. (vCPEResCus -> DoCreateVfModule -> (has VNF creation info) -> VNF adaptor -> response from VNF adaptor has Heat stack ID.
- How is this heat stack ID generated in VNF adaptor? Is it fetched from catalog DB? If yes, then we'll need to pass flavor/VMID info to the VNF adaptor and somewhere inside this VNF adaptor, the heat template will be modified with the favor/labelID/vimID info passed and the heat stack ID of this modified heat template is returned.
Update2:
- High level flow when talking to OpenStack directly: vCPE create workflow -> create vnf -> ???? -> MSO vnf adaptor -> MSO adaptor utils -> Heat adaptor (OpenStack)
- High level flow when using Multicloud API: vCPE create workflow -> ???? -> Multicloud API.
Why are there 2 ways of talking to a cloud (multicloud vs direct openstack). In either cases, where are the Heat templates generated? (somewhere in ???? layer).
Update1:
- SO should pass label flavor map (containing HPA) to Heat template to spin those up.
- The high level flow seems to be vCPE create workflow -> create vnf -> ???? -> MSO vnf adaptor -> MSO adaptor utils -> Heat adaptor [1] -> Actual things are spinned up. But all this seem to talking to OpenStack directly using SDK.
- Something should happen in the middle either in ????/MSO vnf adaptor/ which will actually do the mapping and creates the Heat template. This gets used in createStack() [2].
