Cisco Cisco Elastic Services Controller 1.0 Developer's Guide
<escEvent xmlns="http://www.cisco.com/esc/esc">
<status>SUCCESS</status>
<status_message>Successfully recovered VM [csr-reg__12605__vnf-tenant__vnf-
tenantcsr-depcsr-reg1.2__0__csr-vm__0].</status_message>
<svcname>csr-reg</svcname>
<svcversion>1.2</svcversion>
<depname>csr-dep</depname>
<tenant>vnf-tenant</tenant>
<svcid>e20f8ed6-a9cd-4d30-ac5b-6c3be35e38ba</svcid>
<depid>3e0d269a-c3a4-454a-832f-44e0528ed2c1</depid>
<vm_group>csr-vm</vm_group>
<vm_source>
<status>SUCCESS</status>
<status_message>Successfully recovered VM [csr-reg__12605__vnf-tenant__vnf-
tenantcsr-depcsr-reg1.2__0__csr-vm__0].</status_message>
<svcname>csr-reg</svcname>
<svcversion>1.2</svcversion>
<depname>csr-dep</depname>
<tenant>vnf-tenant</tenant>
<svcid>e20f8ed6-a9cd-4d30-ac5b-6c3be35e38ba</svcid>
<depid>3e0d269a-c3a4-454a-832f-44e0528ed2c1</depid>
<vm_group>csr-vm</vm_group>
<vm_source>
<vmid>9b252ece-7973-4b1f-832e-fe53c68fb963</vmid>
<hostid>a2f7615e78330dd28697588ddfb9516504b19642f53d39d7cff4f6ab</hostid>
</vm_source>
<vm_target>
<vmid>250e515b-978f-4358-b455-124b72608ba2</vmid>
<hostid>a2f7615e78330dd28697588ddfb9516504b19642f53d39d7cff4f6ab</hostid>
</vm_target>
<event>
<type>VM_RECOVERY_COMPLETE</type>
<hostid>a2f7615e78330dd28697588ddfb9516504b19642f53d39d7cff4f6ab</hostid>
</vm_source>
<vm_target>
<vmid>250e515b-978f-4358-b455-124b72608ba2</vmid>
<hostid>a2f7615e78330dd28697588ddfb9516504b19642f53d39d7cff4f6ab</hostid>
</vm_target>
<event>
<type>VM_RECOVERY_COMPLETE</type>
</event>
</escEvent>
</notification>
</escEvent>
</notification>
On Failure:
Event notification
An escEvent of type VM_RECOVERY_COMPLETE with a status of FAILURE will be sent to Netconf
subscribers if the recovery workflow results in a failure. If a FAILURE event occurs, there may be cleanup
required as described below under Handling Recovery Failures.
subscribers if the recovery workflow results in a failure. If a FAILURE event occurs, there may be cleanup
required as described below under Handling Recovery Failures.
Handling Recovery Failures
If a failure occurs while attempting a recovery, the Netconf client should explicitly bring the
configuration back to a consistent state by sending the corresponding Undeploy service configuration
change. Refer to section 6.1.11 for Undeploy service configuration. The Undeploy would send escEvents
of type VM_UNDEPLOYED , DELETE_SUBNET (if any subnets were created during deployment) ,
DELETE_NETWORK (if any networks were created during deployment) and SERVICE_UNDEPLOYED . The
Deploy service configuration change can then be retried explicitly by the Netconf client once the
underlying issue is resolved. Refer to section 6.1.9 for Deploy service configuration.
configuration back to a consistent state by sending the corresponding Undeploy service configuration
change. Refer to section 6.1.11 for Undeploy service configuration. The Undeploy would send escEvents
of type VM_UNDEPLOYED , DELETE_SUBNET (if any subnets were created during deployment) ,
DELETE_NETWORK (if any networks were created during deployment) and SERVICE_UNDEPLOYED . The
Deploy service configuration change can then be retried explicitly by the Netconf client once the
underlying issue is resolved. Refer to section 6.1.9 for Deploy service configuration.
6.2 Scale Out/Scale in Work Flows
6.2.1
Scale Out Work Flow
A scale-out work flow will be triggered if the current VNF is overloaded. From the user side, no request
is required to triggered a scale-out. The monitors attached to VNF will trigger it if necessary.
is required to triggered a scale-out. The monitors attached to VNF will trigger it if necessary.
6.2.1.1 Event Notifications
There are three notifications sent to NB during a successful scale out:
1. When a scale-out work flow is initiated, the following notifications will be
sent from ESC: