/
ESR Dublin Requirements Collection

ESR Dublin Requirements Collection

Owned by Huabing Zhao
Last updated: Mar 23, 2020 by Byung-Woo Jun
2 min read

Requirements from MultiCloud (@Bin Yang ):

  • User could update cloud region on ESR GUI portal which results ESR issuing POST API request to MultiCloud registration API (@Bin Yang )

  • User could delete cloud region on ESR GUI portal which results ESR issuing DELETE API request to MultiCloud unregistration API (@Bin Yang )

  • User could get indication of the progress of MultiCloud registration/unregistration of the cloud region on ESR GUI portal (status code, message, etc.) (@Bin Yang )

  • ESR could workaround the API request timeout issue which might be a common situation while issuing request to MultiCloud registration/unregistration API via MSB (@Bin Yang )

  • User could could register multiple tenants for a single cloud region while registering a new cloud region or  updating the existing one (@Bin Yang )

  • Fix minor issues: AAI-2041: ESR VIM register dialog does not store ssl cacert into AAIClosedAAI-1949: ESR VIM register dialog cannot populate cloud region version list at the first loadClosed (@Bin Yang )

  • Enhance ESR to register/un-register Kubernetes based Cloud regions (@Srinivasa Addepalli )

    • Ability to register a site with kubeconfig (available as a file with user), which is used to connect to Kubernetes API server of the cloud-region.

    • Flexibility in site registration with additional reachability information.  For example, OVN network controller has its own endpoint information. This is required by K8S plugin to reach OVN from ONAP. In future, there would be need for adding additional network controllers or storage controller and hence there needs to be flexibility to register with more reachability blocks.

    • Dublin simplification considerations:

      • It is okay to assume that all reachability blocks are represented as BLOBs (from user perspective, files) in initial release. That is, there is no need to provide GUI for every element of reachability information. For example, it is okay to expect user to copy and paste kubeconfig file content in ESR GUI. Similarly, it is okay to expect user to provide content as opaque to ESR for OVN reachability and others in future.

    • Some implementation considerations:

      • Minimizing  A&AI changes (Or no changes):  Reachability blobs can be stored in MC K8S Plugin instead of storing in A&AI.  Since MC is called for registering/de-registering cloud-regions, this can be done, I guess.   But, in MC, we need to ensure that the plugins get called for them to take any action on these registration/de-registration/Get requests and that enhancement is required in MC.  That said, if team thinks that A&AI schema can be changed easily, we are okay with that too.

Requirements from SOL 005 use case:

  • As part of SOL 005 usecase, Operator has to register NFVO in ESR with the details including endpoint, credentials, API Root etc., 


Requirements from SOL 003 use case:

  • As part of SOL003 usecase, Operator has to register VNFM in ESR with details including endpoint, credentials, etc.