This Task is a result of discussions around this Bug: https://jira.onap.org/browse/SO-2956

It is proposed to refactor the VID Change Management pages, not to require a generic-vnf<-> vserver relation in order to display a VNF as eligible for VNF Change operation.

Instead it is proposed to check, if there is at least one VF-Module, associated with a generic-vnf object, which has a relation to at least one object of vserver type. That way, the VNF shall be considered as active (a check on "orchestration-status" parameter value equal to "Active "might be introduced too), and equipped with at least a single VM.

Within Scale-out team (csbford, ym9479, platania), we have agreed, that this is currently the best method to check, if a VNF could be a subject for scale-out activity. It would be insufficient to check, if there is an active VF-Module associated with a generic-vnf object, as such a VF-Module might not really deploy the VM (e.g. contains networks set-up only). Based on that, we`ve agreed, that it is necessary to check, if at least 1 vf-module contains a relation to an active vserver instance.

We agreed as well, that an existing requirement on the generic-vnf <-> vserver relation must be removed, as this relation is redundant (and misleading). SO-HeatBridge implementation sets-up a vserver instance relation to a vf-module, and a vf-module is a part of generic-vnf object. Adding a relation between generic-vnf and vserver is wrong, and shall be removed in Guilin release too.

With this task, it is planned to refactor the VID Change Management pages, and adapt it to SO-HeatBridge implementation available starting from ONAP/Frankfurt.