Persistence of HPA related information in AAI
Requirements that are kept in mind are :
Expose HW capability of various CPU architecture (Intel x86, ARM etc...) in generic fashion.
Provide flexibility to expose CPU architecture and vendor specific features.
Support for multiple Clouds such as Openstack clouds, AWS Cloud, Azure Cloud etc...
No hardcoding of HPA feature names OR attribute names in ONAP (other than Multi-Cloud plugin)
Please refer to HPA Requirement & Capability Specification
Following format is used to represent the HPACapability:
Data centers typically have flavors (openstack calls them flavors, Azure calls them VM sizes and AWS calls them as Instance types). Each flavor is represented by hardware features. When these are discovered by ONAP, there are few ways to represent them in A&AI DB.
Approach 1:
flavors as children to the cloud-region (Already existing)
Represent HPA capabilities under each flavor (HPA capabilities as children of each flavor)
Approach 2:
flavors as children to the cloud-region (Already existing). Also, represent HPA capabilities also children to the cloud-regions.
Then provide relationship between flavors and capabilities.
Approach 3:
Approach 1 +
Create another tree with capability to region+flavor list.
Which approach to follow? Some guidance from A&AI team. Requirement is this:
During VNF instantiation, OOF gets hold of hardware requirements and based on that requirements, it needs to find out the best cloud-region and flavor.
Would Approach 3 seem possible?
Each HPACapability is defined as
{HPACapability-id,HPAFeature, Schema Version, hardware-architecture, [List of HPAAttributes] - names and values}HPAFeatureAttribute is <hpaAttributeKey, hpaAttributeValue>
Refer Supported HPA Capability Requirements(DRAFT) for more specific Capability names and values.
A&AI Schema Changes
Example: Run time view of A&AI graph instance
Sequence Diagrams
Discovery of HPA-flavors when cloud-region is added
Periodic Discovery of HPACapabilities
VNFC Instantiation
TBD
Following table provides HPA features and attributes. Also, it describes matching constraints for each HPA feature. These constraints are applied while finding the best cloud-region for placing VNFC.
Attributes are represented as:
TBD...
<HPA feature name |
|
|
|
|---|
AAI APIs for HPA :
TBD
Comments
@Srinivasa Addepalli the new term has been chosen. Going forward, we've agreed to use HPA (Hardware Platform Awareness) instead of EPA.
The updated proposal and list of participating companies is available here: https://lf-onap.atlassian.net/wiki/download/attachments/16259089/onap-hpa-requirements.pptx?api=v2
Explicitly tying OpenStack flavors and HPA capabilities is problematic for a number of reasons, not the least of which is that we would be tying operators to a specific flavor creation/scheme. What we have discussed before was an approach where for each VIM we would model a list of higher order features, with HPA being one of them. This way we can distinguish between VIMs capable/willing to expose HPA information and those that are not. If HPA information is available, we would express it as an array of tuples using the following format...
(architecture-spec, capability-name, capability-value)
where:
architecture-spec | a character string that defines the hardware architecture |
capability-name | a character string that defines the name of a specific HPA capability |
capability-value | a character string that defines the value of a given HPA capability |
Observe that the tuples are hardware vendor specific. Each vendor would be unique identified by the <architecture-spec> string. The names and values of capabilities would also be vendor-specific.
During optimization of homing and placement, hardware specific OOF plugins could be used to interpret the names/values of VNFD requirements and match them as appropriate against capabilities listed in the AAI.
I agree. In fact, the concept of "flavors" or "groups" in general is problematic in itself from an orchestration perspective. It either requires defining standard types of flavors, or some type of central "clearinghouse" where VNF designers can go look up what flavors are available and likely to be recognized by orchestrators. Lacking that, there is not guarantee that any flavor specified in the VNF descriptor will be meaningful. Alex' proposal of just specifying a list of tuples is much simpler.
As per F2F discussion at Santa Clara conference, replaced the term "compute-group" with "EPA-flavor".
There were few objections on the term EPA itself. Once the new term is chosen, this page would be updated accordingly.