Instantiation - SDN-C Generic Resource API (Enhancement)

SDNC Modeling Process (via Controller Design Studio UI).

1. Heat Mapping: Start by the HEAT environment file as final product required for Openstack spin up. Then for each cloud parameter we define the following:
   1. Cloud parameters assignment type (Default, Input, Capability)
   2. Resources ruleset (Assignment logic : Recipe, ingredients, Model-driven vs Custom logic)
   3. Assignment Capabilities: (microServices, DG-Capability logic, Policy models...)
   
   
2. Data Dictionaries: Define the SDNC model used to resolve resource values from various systems.
   1. Define source type (default. Input, DB, A&AI, mS…etc)
   2. Define model used to retrieve the resource value from the various sub-systems (input-key-mapping, output-key-mapping, url, path)
   3. Define DD’s name, type, complex data type (if sub-system supports a list of complex data structure)
   
   
3. Controller Blueprint: Create SDNC model and all associated capabilities, artifact templates, Data Dictionaries
   1. model Identifier: (model name, version, author…etc)
   2. Capabilities ( Resource-Assignment, Artifact-template)
   3. Template Instance (Upload Artifact Templates)
      1. Edit/View each Artifact Template
      2. Upload Artifact Template JSON file
      3. Load template and Auto-Map to Data Dictionaries
      4. Review Mapping Table and Edit DDs, Default values, DD Source

Overview

The generic-resource-api is used to assign cloud parameter assignment during instantiation flow. The vf-module instantiation flow begins with the main DG, self-serve-vfmodule-assign, when the svc-action = assign in the rpc request.

The main DG will call a series of sub-DGs according to the execution order of all the predefined capability components, such as generate-name, vlan-tag-assignment, eipam-ip-assignment, etc.

For IP assignment, the main DG calls the sub-DG, self-serve-eipam-ip-assignment to start the ip assignment process.

This wiki serves as the blueprint for capability integration with generic-resource-api for ip assignments, and it is used to integrate EIPAM custom plugin to obtain ip address assignments during vf-module orchestration.

Prerequisite                  

The following parameters must be set in context memory prior to the self-serve-eipam-ip-assignment sub-DG is called.

• ss.capability-name
  • value that matches the capability DG name; i.e. self-serve-eipam-ip-assignment
• ss.capability-action
  • assign
• vnf-index
  • The array index of the vnf that owns this vf-module in config tree
• vf-module-index
  • The array index of this vf-module in config tree
• service-data.vnfs.vnf[$vnf-index].vnf-data.vf-modules.vf-module[$vf-module-index].vf-module-data.vf-module-topology.vf-module-parameters.param[].

Logic

1.   Unresolved Parameter Resolution

-        Calls self-serve-capability-param-resolution DG to resolve all the unresolved values in vf-module-parameters.param[].resource-resolution-data.resource-key[].value where resource-resolution-data.capability-name matches this DG name.

2.   Call EIPAM Plugin

-        The EIPAM plugin returns the ip assignment in a context variable, called eipam-ip-block

-        eipam-ip-block.plans[].requests[].ip-prefix

-        eipam-ip-block.plans[].requests[].ip-prefix-length

-        eipam-ip-block.plans[].requests[].ReservedAssignments[0]. ReservedAssignment[3].ReservedKeyIPAddress

-        Insert an entry to EIPAM_IP_ASSIGNMENTS table

3.   Set Heat Parameters

The sub-DG, self-serve-vfmodule-assign will set value of then heat parameters based on the EIPAM

-        vmxvre_oam_ip_0 = eipam-ip-block.plans[].requests[].ip-prefix

-        vmxvre_oam_ip_prefix_0 = eipam-ip-block.plans[].requests[].ip-prefix-length

-        vmxvre_oam_gateway = eipam-ip-block.plans[].requests[].ReservedAssignments[0].

-        ReservedAssignment[3].ReservedKeyIPAddress

Overview

The generic-resource-api is used to unassign cloud parameters during the vf-module unassign flow. The vf-module unassign flow begins with the main DG, self-serve-vfmodule-unassign, when the svc-action = unassign in the rpc request.

The main DG will call a series of sub-DGs according to the execution order of all the predefined capability components, such as generate-name, vlan-tag-assignment, eipam-ip-assignment, etc to unassign cloud parameters.  Upon successful unassignment, the main DG will clear the service-data data in MD-SAL

Prerequisites

The following parameters must be set in context memory prior to the self-serve-eipam-ip-assignment sub-DG is called.

• ss.capability-name

  • value that matches the capability DG name; i.e. self-serve-eipam-ip-assignment

• ss.capability-action

  • unassign

• vnf-index

  • The array index of the vnf that owns this vf-module in config tree

• vf-module-index

  • The array index of this vf-module in config tree

• service-data.vnfs.vnf[$vnf-index].vnf-data.vf-modules.vf-module[$vf-module-index].vf-module-data.vf-module-topology.vf-module-parameters.param[].

Logic

1.   Set EIPAM_IP_ASSIGNMENTS status

• set EIPAM_IP_ASSIGNMENTS.status t0 PENDING_DELETE by service-instance-id and client-key

2.   Call EIPAM Plugin unassignIp

• Calls EIPAM plugin unassignIp method to unassign ip from EIPAM

3.   Set Heat Parameters status

• Set service-data … vf-module-parameters.param[].resource-resolution-data.status to DELETED for the following params

  • vmxvre_oam_ip_0

  • vmxvre_oam_ip_prefix_0

  • vmxvre_oam_gateway

Netbox Capability: