Candidate schema
- dhebeha mj
Base Candidate Class
Attribute | Required | Content |
|---|---|---|
inventory_provider | Y | String |
inventory_type | Y | String |
candidate_id | Y | String |
candidate_type | Y | String |
uniqueness | Y | Boolean |
cost | Y | String |
Inventory Types
1) Cloud
2) Service
3) Vfmodule
4) Transport
All the candidate for every inventory types extend from the candidate base class.
Following are the AAI objects from which the respective candidates takes the required data:
Cloud object
EXAMPLE : https://docs.onap.org/projects/onap-optf-has/en/latest/sections/homingspecification.html
MODEL
Attribute | Required | Content |
|---|---|---|
cloud-region | Y | dict |
complex | Y | dict |
flavors | Y | dict |
sriov_automation* | N | boolean |
Service object
EXAMPLE : https://docs.onap.org/projects/onap-optf-has/en/latest/sections/homingspecification.html
MODEL
Attribute | Required | Content |
|---|---|---|
generic-vnf | Y | dict |
vlan_info* | Y | dict |
cloud-region | Y | dict |
service-instance | Y | dict |
complex | Y | dict |
sriov_automation* | N | boolean |
Vfmodule object
EXAMPLE : https://docs.onap.org/projects/onap-optf-has/en/latest/sections/homingspecification.html
MODEL
Attribute | Required | Content |
|---|---|---|
generic-vnf | Y | dict |
cloud-region | Y | dict |
vlan_info* | Y | dict |
vserver | Y | dict |
service-instance | Y | dict |
vf-module | Y | dict |
complex | Y | dict |
l-interfaces | Y | dict |
sriov_automation* | N | boolean |
Transport object
EXAMPLE : https://docs.onap.org/projects/onap-optf-has/en/latest/sections/homingspecification.html
MODEL
Attribute | Required | Content |
|---|---|---|
service-instance | Y | dict |
complex | Y | dict |
zone | Y | dict |
Design
In the data module, after fetching the data from AAI the candidate gets populated like this
While returning to solver;