A&AI Schema
ComputeNode, HPACapacity schema
...
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
{
"from": "compute-node",
"to": "cloud-region",
"label": "org.onap.relationships.inventory.BelongsTo",
"direction": "OUT",
"multiplicity": "MANY2ONE",
"contains-other-v": "!${direction}",
"delete-other-v": "NONE",
"SVC-INFRA": "NONE",
"prevent-delete": "!${direction}",
"default": "true",
"description":""
},
{
"from": "compute-node",
"to": "flavor",
"label": "org.onap.relationships.inventory.AssociatedWith",
"direction": "OUT",
"multiplicity": "MANY2MANY",
"contains-other-v": "!${direction}",
"delete-other-v": "NONE",
"SVC-INFRA": "NONE",
"prevent-delete": "!${direction}",
"default": "true",
"description":""
}
|
Changes Required in OOF HPA constraint
...
return from List of HPACapacity.get(hpaCapacityKey)
Flavor - HPACapability Schema during HPA Discovery
HPACapability in Flavor needs to filled with an additional metadata for capacity check named hpaCapacityKey which is used to find the capacity from compute Node. (Marked in RED)
Because of certain grouping of HPACapabilities, we need to add the hpaCapacityKey metadata inside the individual hpa-attribute-value (eg: basicCapabilities where each of the hpa-attributes needs capacity check)
In Case of Pciepassthrough, the HPAAttributes together represent an individual capability, so the hpaCapacityKey is formed in a composite manner including the pcieVendorId and pcieDeviceId. The pciCount is used in capacity check.
During HPA discovery process, Multicloud will add the necessary metadata for simplifying capacity check.
Refer wiki page: https://wiki.onap.org/display/DW/Policy+Specification+and+Retrieval+for+OOF
...
Policy
...
Attributes
...
hpa-feature
...
Openstack Mapping
...
AAI Flavor HPACapability representation (Eg:)
...
HPA Basic Capabilities Policy Example
...
numVirtualCpu
virtualMemSize
...
basicCapabilities
...
vcpus,
ram
hpa-capability-id="b369fd3d-0b15-44e1-81b2-6210efc6dff9",
hpa-feature=”basicCapabilities”,
architecture=”generic",
version=”v1”,
...
hpa-attribute-key
...
hpa-attribute-value
...
numVirtualCpu
...
{value:4, hpaCapacityKey: "basicCapabilities_numVirtualCpu"}
...
virtualMemSize
...
{value:4, unit:”MB”, hpaCapacityKey: "basicCapabilities_virtualMemSize"}
...
HPA PCIe Passthrough Policy Example
...
pciCount
pciVendorId
pciDeviceId
...
pciePassthrough
pci_passthrough:alias=ALIAS:COUNT
Openstack administrator is expected to create ALIAS as
<name>-<PCIe vendor ID in Hex>-<PCIe device ID>
QuickAssist example: "mycrypto-8086-0443"
In case of SRIOV-NIC:
aggregate_instance_extra_specs:sriov-device-<name>="<Vendor ID>-<Device ID>"
It is expected that Openstack administrator creates host aggregate and metadata 'sriov-device-<name>' .
Example: Assume that there are two SRIOV-NIC cards supported by a region, Intel and Mellanox.
Examples:
sriov-device-intel=8086-1563
sriov-device-mellanox=15B3-1003
hpa-capability-id="f453fd3d-0b15-11w4-81b2-6210efc6dff9",
hpa-feature=”pciePassthrough”,
architecture=”intel64",
version=”v1”,
hpa-attribute-key | hpa-attribute-value |
---|---|
pciCount | {value: 1} |
pciVendorId | {value: "8086"} |
pciDeviceId | {value: "0443"} |
hpaCapacityKey: | "pciePassthrough_8086_0443" |
hpa-capability-id="q236fd3d-0b15-11w4-81b2-6210efc6dff9",
hpa-feature=”pciePassthrough”,
architecture=”{hw_arch}",
version=”v1”,
hpa-attribute-key | hpa-attribute-value |
---|---|
pciCount | {value: 1} |
pciVendorId | {value: "15B3"} |
pciDeviceId | {value: "1003"} |
SR-IOV | {value: "physnet"} |
hpaCapacityKey: | "pciePassthrough_15B3_1003" |
...
HPA Huge Pages Policy Example
...
memoryPageSize
...
hugePages
...
hw:mem_page_size
values can be ANY, 4KB, 2MB, 1GB
How to handle large, small, any from openstack?
if the hw:mem_page_size is an integer it is assumed the unit is in KB
The deafult value for small page is 4k, for large page is 2M or 1G(recommended value 2M), for any page, libvirt will firstly to try to find large pages, if failed then will fall back to small pages. so it's suggest do not support any page in current release version
hpa-capability-id="e769fd3d-0b15-77b3-81b2-6210efc6dffa",
hpa-feature=”hugePages”,
architecture=”generic",
version=”v1”,
...
hpa-attribute-key
...
hpa-attribute-value
...
memoryPageSize
...
Maintain HPA JSON Metadata file in Multicloud and OOF (Most of it is static information)
"HPA_feature_qualifications"
: {
"HPA_features"
[
{
"HPA feature name"
: <
"HPA feature name AKA HPA capability Name"
>
"HPA capacity matching attributes"
[
"<Attribute Name>"
}
],
"HPA capacity check attribute"
: <
"Attribute Name"
>
]
}
Example configuration file:
"HPA feature qualifications"
:{
"HPA features"
: [
{
"PCIePassthrough"
, [
"pciVendorid"
,
"pciDeviceID"
],
"pciCount"
},
{
"basicCapabilites"
, [
"numVirtualCPU"
],
"numVirtualCPU"
},
{
"basicCapabilities"
, [
"virtualMemSize"
], "virtalMemSize:}
]
}
OOF - Generate the composite hpaCapacityKey
Examples of forming the composite key from the metadata file during capacity check.
HPAFeature | HPACapabilityAttribute | Composite hpaCapacityKey |
---|---|---|
basicCapabilities | numVirtualCpu | basicCapabilities_numVirtualCpu |
basicCapabilities | virtualMemSize | basicCapabilities_virtualMemSize |
pciePassthrough | pciVendorId pciDeviceId | pciePassthrough_${pciVendorId}_${pciDeviceId} ${VAR} - replace with the hpa-capability-attribute-value |
hugePages | memoryPageSize | hugePages_memoryPageSize_4KB hugePages_memoryPageSize_2MB hugePages_memoryPageSize_1GB |