Dear team,
Thanks for joining this meeting, it is really helpful to get everyone on the
same page, please refer to following MoM
(https://wiki.onap.org/pages/viewpage.action?pageId=48529981)
Valet/F-GPS disucssion, Dec. 14th 2018
Attendees:
Bin Yang,
Ethan Lynn,
Gueyoung Jung,
Matti Hiltunen,
Bin Hu,
Haibin Huang
Sudhakar Reddy,
Xinhui Li
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://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
Best Regards,
Bin Yang, Solution Engineering Team, Wind River
ONAP Multi-VIM/Cloud PTL
Direct +86,10,84777126 Mobile +86,13811391682 Fax +86,10,64398189
Skype: yangbincs993
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#14503): https://lists.onap.org/g/onap-discuss/message/14503
Mute This Topic: https://lists.onap.org/mt/28749180/21656
Group Owner: [email protected]
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
