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]> 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 (#14509): https://lists.onap.org/g/onap-discuss/message/14509 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]] -=-=-=-=-=-=-=-=-=-=-=-
