Please refer to the design spec for details

https://gerrit.onap.org/r/#/c/29419/2/docs/specs/MultiCloud-HPA-Discovery-design.rst



Proposed alternative solutions to discover HPA information
==========================================================

While it is up to each MultiCloud Plugin service to determine how to discover
HPA information, there are several alternative solutions to accomplish such
discovery process.

Solution 1: Hard-coded discovery
--------------------------------

The MultiCloud services are designed in the way that there will be specific
plugin service to adapting ONAP into specific type or flavor of VIM/Cloud,
so the specific MultiCloud plugin service is tightly coupled with the
corresponding VIM/Cloud type or flavor. If some kinds of HPA information are
statically pertaining to a VIM/Cloud type or flavor and invariant between
different instance, it will be possible to hard coding this HPA information
into the corresponding MultiCloud Plugin Service. One example is that Titanium
Cloud comes along with builtin HPA feature of vswitch with DPDK support, so
this HPA information will be hard-coded into MultiCloud plugin service for
Wind River Titanium Cloud.


Solution 2: Manually discovery
------------------------------

There are some kinds of HPA information which vary between instances of the
same VIM/Cloud type, but will be invariant during the whole life-cycle of
that instance. These information can be manually injected into ONAP during
the VIM/Cloud instance onboarding process. There is a field named
"cloud extra info" from the ESR VIM registration portal, ONAP users could
input the extra information into ONAP which will be stored into AAI
(refer to property of "cloud-extra-info" of /cloud-infrastructure/cloud-regions
/cloud-region/{cloud-owner}/{cloud-region-id}). So when MultiCloud Plugin
Service are invoked to discover HPA information, the cloud extra information
will be decoded to check if there are HPA information can be extracted and
represented into AAI.


Solution 3: Automatically discovery
-----------------------------------

There are some other kinds of HPA information which changes dynamically
during the life-cycle of a VIM/Cloud instance, so we have to discover them
leveraging some automation approach. While different VIM/Cloud type of flavor
exposes different approach to support the automatical discovery with respect
to HPA resources, the approach is quite straight-forward for OpenStack.
For those HPA information will be consumed by specifying the extra specs of a
flavor, VIM/Cloud administrators could provision these flavor's extra specs
with HPA information before onboarding the VIM/Cloud instance into ONAP.
After VIM/Cloud onboarding to ONAP, MultiCloud Plugin Service for OpenStack
will extract these HPA information from the extra specs of the flavors and
represent them into AAI.


  • No labels

9 Comments

  1. Viswanath Kumar Skand Priya

    Hello,

    I would like to know what is the finalized solution for HPA discovery? ( Solution 1/2/3 ? ) . Is this decision still pending?

    BR,

    Viswa

    1. Srinivasa Addepalli

      Copying Huang Haibin and Nate Potter

      Hi,

      I would not use terms "Manual discovery" and "Automatic discovery". Rather I would use terms "first time discovery" and "continuous discovery".

      First time discovery:  When region is added (via portal) to A&AI,  Multi-Cloud will discover remote VIM flavors, their capabilities and put them in A&AI.

      Continuous Discovery:  Periodically (In R2, it is hardcoded),  Multi-Cloud will discover changes to the flavors in remote VIMs and then updates A&AI DB.

      Discovery example is given in earlier response here:  Re: Hardware Platform Enablement In ONAP

      1. Viswanath Kumar Skand Priya

        Hi Srinivasa Addepalli & others,

        Thanks. Let me summarize my understanding. Please validate.

        • In R2, there will be 2 discovery modes ( First & Continuous ).
        • First discovery will be performed by manually ( or rather administratively ) entering discovery URL of corresponding VIM.
        • Once done, periodically continuous discovery will be kicked off ( whose frequency is hardcoded in R2, but will become configurable in future ) to refresh HPA attributes in AAI.

        Follow-up question : Can discovery be done on-demand anytime? i.e Assume I extend my VIM / created a flavor. Now will I be able to force-refresh ? I assume it can...

        BR,

        Viswa

        1. Srinivasa Addepalli

          Your understanding is correct.  On your second bullet, entering URL, Keystone user name/password are given by administrator anyways. there is no specific URL information to be provided for HPA.

          On-demand discovery: It can be done. But it is not being done for R2. For on-demand discovery,  some GUI is required I guess.

          1. Viswanath Kumar Skand Priya

            Yup I meant Keystone API only. I assume other VIMs have similar approach .

            1. Bin Yang

              I think there are 2 dimensions to "discover" HPA information: When to discover them and how to do that. So the terms "first time discovery" and "continuous discovery" refer to "When", while the proposed solutions on this wiki page refer to "How" . 

              With regarding to "How", all 3 solutions might be leveraged. Depends on how the specific HPA information can be discovered. For sure, as soon as the HPA information can be discovered by rest API to underlying VIM, we prefer automating the discovery process, otherwise we have to do that with solutin 2 or 1.

  2. Pankaj Wanikar

    Bin Yang Does HPA also discover the information regarding the network acceleration technologies like DPDK, SR-IOV, smart NICs etc ? Basis which, the corresponding VNFs can be deployed on the VIM.

    1. Bin Yang

      These HPA discovery are realized case by case, I mean, the source code must be there. For Casablanca Release, DPDK, SR-IOV NIC are discovered and registered according to the end to end requirement. smart NIC discovery is not yet done. Please contact Huang Haibin for the details. Thanks

      1. Srinivasa Addepalli

        Many smart-NICs are treated as any other NIC as far as flavors are concerned : 

        If smartNIC is a PCIe device and exposes virtio-net interface (by itself or via some mediation software in NFVI), then it is like any other PCIe device as far as capability is concerned.

        If smartNIC is a PCIe device and expose HW specific SRIOV VF to VMs, then it can be considered as SRIOV-NIC in ONAP.

        If your smartNIC is one of two above types, then I would say that ONAP supports them.

        If the smartNIC is programmable  (Example: FPGA which allows user programs) , then there is some additional work to be done in ONAP. We are planning to do this once Openstack S is released.