MoM of Valet/F-GPS disucssion, Dec. 14th 2018
- Bin Yang
Attendees: @Bin Yang @ethanlynnl @Gueyoung Jung @Matti Hiltunen @Bin Hu @Haibin Huang @Sudhakar Reddy @Former user (Deleted)
1, Input to re-schedule MC weekly meeting
11am (Which day of week?) Beijing Time (GMT+8) could be the 1st option
Another option is to go with current weekly meeting time slot
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://lf-onap.atlassian.net/wiki/pages/viewpage.action?pageId=16331211
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
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