Page History

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

Execution - Runtime process (via VID to SO to SDNC)

5. Capability DGs execution flow

Logic for vnf and vf-module assignement is pretty much the same. The main difference is, vnf assignment will take care of calling the naming microservice if specified in the controller blueprint artifact.

This is the general logic of the VNF assign flow and sub-flows:

    This is the general logic of the vf-module assign flow and sub-flows:

    call vf-module-topology-operation

        call vf-module-topology-operation-assign

            set service-data based on SO request (userParams / cloudParams)

            call self-serve-vf-module-assign

                set capability.execution-order: this is where we're adding our capability flow: netbox-ip-assign

                call self-serve-vfmodule-ra-assignment

                    execute ConfigAssignment (Resource Accumulator micro-service)

                    put resource-accumulator-resolved-data in MDSAL service-data

                call self-serve- + capability-name, e.g. self-serve-netbox-ip-assign

                    execute NetboxClient assignIpAddress

                put vf-module information in AAI