For anyone interested in the topic, the conversation occurs on the wiki: https://wiki.onap.org/pages/viewpage.action?pageId=48529981
Thanks 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 From: Kumar Skand Priya, Viswanath V [mailto:[email protected]] Sent: Friday, December 14, 2018 3:51 PM To: onap-discuss; Yang, Bin Cc: [email protected]; Huang, Haibin; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [E] [onap-discuss] OOF/MultiCloud Valet/F-GPS deep dive Hi Bin Yang<https://wiki.onap.org/display/~biny993> , I have following queries could you please clarify ? · The check_vim_capacity API input consists of cpu, mem, storage - Is there any API to filter based on HPA attributes, flavor tags ? · Also can the filter fine tune based on provider network names / ids, available free pool of floating ips, neutron ports etc ? · Is there a reserve API available for reserve the resources for a finite amount of time ? · What's the guarantee that the fetched info holds good until a resource allocation request originates from SO ? i.e between the time instance t1 ( capacity check ) and t2 ( instantiation request ) if the resources have been used either by backdoor cloud access or other 3rd party nfv-o / cloud , what's the mitigation plan ? · Is there a different APIs available between capability check ( eg is DPDK available etc... ) and capacity check ( eg is enough ram available etc.. ) ? · Does this apply to K8S based cloud regions as well ? BR, Viswa On Fri, Dec 14, 2018 at 8:17 AM Yang Bin <[email protected]<mailto:[email protected]>> wrote: 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_pages_viewpage.action-3FpageId-3D48529981&d=DwMFAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=9F3pNUkzjE-2v1eTClkRVakDRN8GH7Bm-wt1lWkxoUyyDORTqf5MxNO_GrMBs0gZ&m=iuiYH2S5HBt4yEhSwIcClY2FkYBIPvvu3maU-NULm2o&s=WoF0CGfgrefH_6EALRHTW5T7NEumzELRrI2iTBTZYUE&e=>) 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_pages_viewpage.action-3FpageId-3D45306917&d=DwMFAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=9F3pNUkzjE-2v1eTClkRVakDRN8GH7Bm-wt1lWkxoUyyDORTqf5MxNO_GrMBs0gZ&m=iuiYH2S5HBt4yEhSwIcClY2FkYBIPvvu3maU-NULm2o&s=XAiW8Ih9BhSoYMN6_sI6HetavDld9dQ6VxndHjwG5Uo&e=> 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__onap.readthedocs.io_en_latest_submodules_multicloud_framework.git_docs_specs_multicloud-5Fresource-5Fcapacity-5Fcheck.html&d=DwMFAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=9F3pNUkzjE-2v1eTClkRVakDRN8GH7Bm-wt1lWkxoUyyDORTqf5MxNO_GrMBs0gZ&m=iuiYH2S5HBt4yEhSwIcClY2FkYBIPvvu3maU-NULm2o&s=xUkKk_aJ_YjO2zIiCAq9XgCQIaLx1ehlGkDWWI4q0Gc&e=>) 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 (#14513): https://lists.onap.org/g/onap-discuss/message/14513 Mute This Topic: https://lists.onap.org/mt/28750439/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
