Uploaded image for project: 'Policy Framework'
  1. Policy Framework
  2. POLICY-503

Remove the "vDNS" hardcoding for requestInfo.instanceName field while invoking SO operation for VF module creation

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Won't Do
    • Icon: Medium Medium
    • Casablanca Release
    • None
    • None
    • None

      Background -

      For scale up scenarios (VF Module Create recipe), the closed control loop policy component invokes "VF Module Create" API on SO. The related logic checks existence of VF module name which has the property "is-base-vf-module" as false - as part of it's validation. When this validation succeeds, it replaces the string "Vfmodule" with "vDNS" of the "vf-module-name" field with property "is-base-vf-module" as true. It uses this modified string and passes this as a requestInfo.instanceName field in payload of "VF Module Create" SO API.

      This hard coding should be removed and we need to have a cleaner way to support this scenario. Additionally in the current design we would not be able to scale-up from 3rd instance, because the policy would not be able to determine the correct VF module, if there are multiple non-base VF modules.

      To address all these aspects, below is the solution suggested -

      The prerequisite for this scenario is that the non-base VF module has to be created using AAI API and not through the VID GUI - during first time service instantiation. Thereafter policy should have the logic so that the instance could be scaled up multiple times without any need for manual configurations. We shall be using the field "orchestration-status" to determine which VF module needs to be instantiated.

      1. Determine the "vf-module-name" which needs to be scaled up. For this, select from the AAI named query response - the "vf-module-name" which has fields "is-base-vf-module" as "false" and "orchestration-status" as "inactive"
      2. Do not replace / modify the field "vf-module-name" determined above
      3. Pass the same "vf-module-name" retrieved above in the requestInfo.instanceName field of the SO payload
      4. Invoke the NEW SO API (Story SO-361) specifically designed for scale-up scenarios. The payload schema remains the same as that of "VF Module Create" API

      After all these steps, for the next scale-up of the same instance to happen, a new VF module with "orchestration-status" as "inactive" and related SDNC configurations also needs to be done. This is proposed to be implemented in new SO API / workflow.  

      Story SO-361 has been created to develop a new SO API / workflow to support specifics of scale-up scenario.

            swapnilpathak swapnilpathak
            milindj milindj
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: