Cisco Cisco Elastic Services Controller 2.1 Developer's Guide
2.2 Writing Configuration Data (CRUD operations)
Create, Update, or Delete operations are performed on configuration data through the standard
Netconf edit-config request. By default, only nodes that are explicitly specified in the edit-config
request will be changed (see Netconf specification for more details).
Netconf edit-config request. By default, only nodes that are explicitly specified in the edit-config
request will be changed (see Netconf specification for more details).
Most configuration changes in ESC follow a two-stage model. The first stage begins when the Netconf
request is received, and ends when the response is returned to the Netconf client. If the request is
validated and the configuration accepted during the first stage, then the configuration workflow
transitions to the second stage, which occurs asynchronously inside ESC. The second stage involves
processing the workflow and activating the change in ESC and in the VIM. These two stages are
described in more detail below.
request is received, and ends when the response is returned to the Netconf client. If the request is
validated and the configuration accepted during the first stage, then the configuration workflow
transitions to the second stage, which occurs asynchronously inside ESC. The second stage involves
processing the workflow and activating the change in ESC and in the VIM. These two stages are
described in more detail below.
2.2.1 Stage 1: Acceptance or Rejection of a Configuration Request
A Netconf rpc-reply response is returned to indicate the status of the configuration request. This
response will indicate whether the configuration request was accepted or rejected by ESC.
response will indicate whether the configuration request was accepted or rejected by ESC.
The rpc-reply response will contain a status body:
A Netconf ok status inside the rpc-reply means that the configuration request was validated and
accepted by ESC. E.g.:
accepted by ESC. E.g.:
<rpc-reply message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<ok/>
</rpc-reply>
An ok status indicates that the data model has been updated with the new configuration, and the
workflow for activating the configuration has been submitted for asynchronous processing.
workflow for activating the configuration has been submitted for asynchronous processing.
A Netconf rpc-error status inside the rpc-reply means that the configuration request failed
validation and was rejected by ESC. E.g.:
validation and was rejected by ESC. E.g.:
<rpc-reply message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-path xmlns:esc="http://www.cisco.com/esc/esc">/rpc/edit-
config/config/esc:esc_datamodel/esc:tenants/esc:tenant/esc:name
</error-path>
<error-message xml:lang="en">"" is not a valid value.</error-message>
<error-info>
<bad-element>name</bad-element>
</error-info>
</rpc-error>
</rpc-reply>
<rpc-error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-path xmlns:esc="http://www.cisco.com/esc/esc">/rpc/edit-
config/config/esc:esc_datamodel/esc:tenants/esc:tenant/esc:name
</error-path>
<error-message xml:lang="en">"" is not a valid value.</error-message>
<error-info>
<bad-element>name</bad-element>
</error-info>
</rpc-error>
</rpc-reply>
An rpc-error status indicates that the configuration in ESC remains unchanged and there is no
further cleanup required in ESC or in the VIM to back-out the change. As shown above, the rpc-
error body contains information about the error that occurred.
further cleanup required in ESC or in the VIM to back-out the change. As shown above, the rpc-
error body contains information about the error that occurred.