on other VFs. For example, a failed instance as part of a cluster configuration should not impact the clus- ter either during failure or restoration. Automation of recovery should be the desired behavior for facilitating fast VF recovery and can be achieved, for example, using ONAP closed-loop analytics and control. 5.3.2.6 VF Software Stability VF software should be capable of supporting configuration parameter changes in such a way as to minimize the need to restart a service. Given that software can fail, just like the underlying infra- structure, the stability of the VF software should be tested with particular focus on resiliency and failover. Stability can also be achieved during upgrades by having the ability to quickly and easily revert to an earlier version if issues are found in a particular version of the VF software. In addition, stability can be achieved by providing the ability for multiple versions of VF software to coexist in order to eliminate the need to migrate all instances of the VF at one time, as opposed to rolling upgrades as needed by the business. 5.3.3 SOFTWARE RESILIENCY ENGINEERING Software resiliency engineering is a longstanding discipline with well-known methods of evaluat- ing software readiness for deployment (Lyu, 1996; Musa, 1999). Techniques to harden software to increase overall resiliency include software development best practices, software architecture reviews, testing methodologies, and stability prediction methods and tools. Testing methodolo- gies are often restricted to feature functionality, during which faults may be uncovered and serve as a data source for residual fault prediction (Hoeflin, 2005; Zhang, 2009). Fault classification has been well defined in standards bodies (IEEE Computer Society, 2010), although in practice, classification is often provided by application testers as defects are discovered and vetted. In addi- tion to fault analytics based on testing, introducing faults into software is another technique that is employed in cloud technologies. Netfli