Versions Compared

Old Version 1

changes.mady.by.user Bin Yang

Saved on

compared with

New Version Current

changes.mady.by.user Bin Yang

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Attendees: Bin Yang,Ethan Lynn,Gueyoung Jung,Matti Hiltunen,Bin Hu,Huang Haibin HuangSudhakar Reddy,

Xinhui Li

 xinhuili


1, Input to re-schedule MC weekly meeting

...

               Will set up a poll for this re-scheduling 


2, OOF -> MC capacity check : 


Background/context:

 


OOF capacity_check workflow works in the best-effort approach to optimize the placement/homing of a VNF. However, there are numerous reasons/chances that the instantiation of a VNF might fail, the inappropriate placement decision could be just one of them. This issue should be resolved in a bigger context/workflow which handles the failing of a VNF instantiation

 


Resource Reservation could be an option to secure the placement/homing decision, but the workflow on that front would be complicated as well, OOF/SO/MC/VF-C will be involved to handle the resource reservation/cancelling/commit/etc. So it is not in scope of Dublin yet. 

 



Workflow: https://wiki.onap.org/pages/viewpage.action?pageId=45306917 


OOF issues the capacity_check API call once for each VNF (not for each VDU placement) 


MultiCloud returns a list of the valid cloud regions, each cloud region will be associated with available capacity info( with AZ names) at AZ level only in case that the available capacity info is available on that cloud region. That implicates for certain cloud region in that list, the  available capacity info at AZ level could be missing. OOF is expected/guaranteed to treat these cloud region as having infinite available capacity on every AZ. 


OOF select cloud region and AZ name, pass the AZ name to SO which forward to MC. This is the same approach for passing flavor selection from OOF->SO->MC

 

 



API spec: 


Request:

The same as current v0/capacity_check

(https://onap.readthedocs.io/en/latest/submodules/multicloud/framework.git/docs/specs/multicloud_resource_capacity_check.html)

 


Response:

VIM (cloud-region) list with a list of AZ capacity information for each VIM

 

 



API version:

Ethan suggest to keep v0/capacity_check be intact, the v1/capacity_check will reflect the changes/upgrades. This could be 1 option to be further discussed.

Bin: I would suggest this v1/capacity_check supports “consistent ID of a cloud region” to identify a VIM by composite keys: {cloud-owner},{cloud-region-id} (instead of {vim-id} in v0/capacity_check).

 

 



Azure plugin:

There is no capacity info at Infrastructure level, but still the limit/quota at subscription level could be useful. So Azure plugin will expose that kind of information to OOF as well