Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Contributors

Keong Lim

Glossary

TermDefinition
producer-consumer pairings

Apart from "internal" AAI data, the data in AAI is produced by a non-AAI component and then consumed by another non-AAI component. Therefore the schema definitions and intended meanings of each schema element is not controlled by AAI itself.


References

Producer-Consumer Pairs

ProducerConsumerAAI RepresentationScenario and References
SOClosed Loop

the "input-parameters" attribute of "service-instance" object described as:

"String capturing request parameters from SO to pass to Closed Loop."

Closed loop scenario:

  • SO will create “service-instance” object in AAI
  • SO will store “customer-request” string on service-instance object in AAI
  • When Closed Loop call recreates the “service-instance”, it will query “service-instance” information first, to get the “customer-request”

References

SOExtAPI(see above?)(see above?)
OOFVFC
  • the "flavor name" attribute of "flavor" object
  • the "flavor id" attribute of "flavor" object

scenario:

  • VFC component sources the "flavor name" from OOF component
  • Then VFC searches AAI using "flavor name" to find the corresponding "flavor id"
  • Finally "flavor id" is used to create a VM

References

SDCVID
  • /service-design-and-creation/models
  • custom query

scenario:

  • SDC distributes models into AAI
  • Then VID calls custom query in AAI to get models by distribution status
  • Finally VID uses models for its functions (this is the main flow for VID)

References

Multi-VIM / CloudOOF
  • /cloud-infrastructure/cloud-regions/cloud-region/{cloud-owner}/{cloud-region-id}/availability-zones

Scenario:

  • Multi-VIM / Cloud collects Availability-Zone capacity data from Clouds into AAI
  • OOF retrieves Availability-Zone information of each Cloud Region from AAI
  • OOF makes homing / placement decisions for VNFs to support "teaming" use case

References

VNFM / ESRVIM / VFC

  • "ssl-cacert" attribute on /esr-system-info-list/esr-system-info/{esr-system-info-id}

  • vs "certificateUrl"

Question:

  • is it just a URL to a certificate file?
  • or is it the literal contents of a certificate file?

Scenario:

  • VIM is registered to ESR including SSL certificates
  • VNFM is registered to ESR including SSL certificates
  • VFC retrieves connection details including SSL certificates
  • VFC logs in to perform its control functions

References:

tbcetc



  • No labels