Contents
If an operation fails in ESC, the user must cancel that operation. ESC will not rollback automatically to cancel any operations. The table below shows the error condition, and recovery details.
Notification or Logging details for Error Conditions
Typically, for all error conditions, an error notification of the failed request will be sent to the NB client (ESC User) through callback if using REST interface, or through netconf notification if using NETCONF interface. An error log will be generated and sent to syslog, if syslog is configured.
Error Condition |
Recovery |
|---|---|
Failed create tenant request |
NB client (ESC User) has to send in a delete tenant request before attempting to send in the same create tenant request |
Failed create network request |
NB client (ESC User) has to send in a delete network request before attempting to send in the same create network request |
Failed create subnet request |
NB client (ESC User) has to send in a delete subnet request before attempting to send in the same create subnet request |
Failed service registration request |
NB client (ESC User) has to send in an unregister service request before attempting to send in the same service registration request |
Failed deployment request |
NB client (ESC User) has to send in an undeploy request before attempting to send in the same deploy request If a deployment fails, ESC updates information in its database (with error state) until it receives an undeployment request. The undeployment will remove objects that are in error states. |
Failed Recovery |
The existing deployment is not usable anymore. NB client (ESC User) has to send in an undeploy request then the same deploy request. |
Failed Scale Out/In |
No action required. The existing deployment is still functional. If at a later stage an undeploy was triggered, it will clean up any VMs that were affected part of the failed scale out and scale in. |
Failed Service Update |
No action required. The existing deployment is still functional. Any retries of that update will not be honored. If at a later stage an undeploy was triggered, it will clean up any created VMs part of the failed update. |
Failed VM Operations (Start, Stop, Reboot, Enable Monitor, Disable Monitor) |
No action required. The existing deployment is still functional. NB client (ESC User) can retry the failed operation. |
Failed VNF/Service Operations (Start, Stop, Reboot, Enable Monitor, Disable Monitor) |
No action required. The existing deployment is still functional. NB client (ESC User) can retry the failed operation. |
Failed delete tenant request |
Possibility of leaking resource in VIM. Manual intervention might be needed to clean up leaking resources on VIM. |
Failed delete network request |
Possibility of leaking resource in VIM. Manual intervention might be needed to clean up leaking resources on VIM |
Failed delete subnet request |
Possibility of leaking resource in VIM. Manual intervention might be needed to clean up leaking resources on VIM |
Failed service unregistration request |
Possibility of leaking resource in VIM. Manual intervention might be needed to clean up leaking resources on VIM |
Failed undeployment request |
Possibility of leaking resource in VIM. Manual intervention might be needed to clean up leaking resources on VIM |
Log messages are created for ESC events throughout the VNF life cycle. These can be external messages, messages from ESC to other external systems, error messages, warnings, events, failures and so on. The log files can be found at /var/log/esc/.
The log message format is as follows:
timestamp threadname loglevel [filename:methodname():line#] [transactionId] [classification] [tags] message
The following classifications are supported:
SM—stands for StateMachine. This classification indicates logs in the StateMachine category.
REST_EVENT—indicates REST EVENTS in logs. This is used by ESC UI.
Classifications and tags are optional. These are prefixes added to the log messages to enhance readability, and help in debugging. With classifications and tags, the log messages can be easily parsed and filtered by log analysis tools.
Further, ESC logs can also be forwarded to an rsyslog server for further analysis and log management.