Introduction

In R2,  HPA is introduced and proven with vCPE use case (with HEAT). It is called 'Policy based HPA' as it requires creation of HPA policies and association of them with VNFs.

In R3,  HPA functionality is extended to cover

  • All use cases that are orchestrated by SO such as vCPE, vFW and vDNS.
  • Use cases that use VFC.  Proven by vCPE-TOSCA.

Also,  R3, many additional capabilities are introduced such as

  • Support for SRIOV-NICs.
  • Selection of best cloud region based on the HPA match score.
  • OOF directives to include HPA flavor name.
  • etc..

Release 4 Goals

In R4,  our main focus is to harden HPA feature, make it easily deployable create literature and create easy-to-replicate demos.

Also, fix any gaps and bugs that are discovered during hardening and testing.

Our aspiration is also to make existing use cases always leverage HPA functionality. As part of that, work with integration team to figure out the way to use HPA in basic integration testing.


Release 4 activities (This section is to-be-completed)

  • Enhance test setup in Intel/WR lab
    • Have few compute nodes with right HW
      • Ensure to have SRIOV-NIC cards
      • Ensure to have crypto accelerator cards (QAT)
  • Ensure that vFW sample VNF works with SRIOV-NIC VFs
  • Create a new sample VNF (IPSEC VNF) for them to leverage crypto accelerator cards.
    • Start with traditional Ubuntu with QAT driver installed.
  • Create new test cases with various HPA features assigned to VNFs.  Few example:
    • vFW with dedicated cores, SRIOV-NIC VF, Huge pages
    • vIPSEC with QAT
    • vIPSEC with AES-NI
  • Work with Integration team to add the test cases in integration project.
  • Work with demo repository owners to introduce new sample VNFs and add new HEAT/ENV files for existing use cases


  • No labels

2 Comments

  1. Bob Monkman

    With respect to vendor proprietary features, such as QAT, as long as the HPA implementation does not require that VNFs rely upon vendor proprietary/exclusive technology, this notion of HPA enabling VNFs to take advantage of unique hardware capabilities is a good thing. It is all about the abstraction and we assume the key value pairs methodology discussed for HPA allows for sufficient abstraction, such that no vendor lock-in is inherently required. Does this make sense?

    1. Srinivasa Addepalli

      HPA feature itself is implemented in hardware agnostic fashion.  The purpose of HPA is to ensure that VNFs that take advantage of specific hardware features (such as QAT, Nitrox-3, NVDIA GPU etc..) are placed in the right cloud-regions that have servers with appropriate hardware.