changing config from a defaulted choice/case to another case doesn't work via NETCONF

[ares1025]

Getting misleading error message when setting manual pump current for CL BiDi L band module.

The configuration seems to be correct, but the cli responds with error.

The command sequence and cli responses are the following:

/> set czechlight-bidi-amp:narrow-1572/pump/manual-current 60
Session 4 [DBG]: Sending message:

#443


Session 4 [DBG]: Sending message:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="71"><edit-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"><datastore xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">ds:candidate</datastore><default-operation>merge</default-operation><config><narrow-1572 xmlns="http://czechlight.cesnet.cz/yang/czechlight-inline-amp"><pump><manual-current>60.0</manual-current></pump></narrow-1572></config></edit-data></rpc>

Session 4 [DBG]: Sending message:

##


Session 4 [DBG]: Received message:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="71"><ok/></rpc-reply>

/> commit 
Session 4 [DBG]: Sending message:

#132


Session 4 [DBG]: Sending message:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="72"><commit xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/></rpc>

Session 4 [DBG]: Sending message:

##


Session 4 [DBG]: Received message:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="72"><rpc-error><error-type>application</error-type><error-tag>operation-failed</error-tag><error-severity>error</error-severity><error-message xml:lang="en">Data for both cases "disabled" and "manual-current" exist. (path "/czechlight-bidi-amp:narrow-1572/pump/control")</error-message></rpc-error></rpc-reply>

Node is not opaque
/> delete czechlight-
czechlight-bidi-amp:c-band/        czechlight-bidi-amp:narrow-1572/   czechlight-system:authentication/  czechlight-system:journal-upload/
/> delete czechlight-bidi-amp:
czechlight-bidi-amp:c-band/       czechlight-bidi-amp:narrow-1572/
/> delete czechlight-bidi-amp:narrow-1572/pump/
agc              disabled         manual-current 
/> delete czechlight-bidi-amp:narrow-1572/pump/disabled 
Session 4 [DBG]: Sending message:

#490


Session 4 [DBG]: Sending message:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="73"><edit-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"><datastore xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">ds:candidate</datastore><default-operation>merge</default-operation><config><narrow-1572 xmlns="http://czechlight.cesnet.cz/yang/czechlight-inline-amp"><pump><disabled xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="delete"/></pump></narrow-1572></config></edit-data></rpc>

Session 4 [DBG]: Sending message:

##


Session 4 [DBG]: Received message:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="73"><rpc-error><error-type>protocol</error-type><error-tag>data-missing</error-tag><error-severity>error</error-severity><error-message xml:lang="en">Node "disabled" to be deleted does not exist.</error-message></rpc-error></rpc-reply>

Node is not opaque

[jktjkt]

This is a combination of several bugs, the first one is that the CLI is currently confused by any NETCONF error message, appparently (which would be #25). The error message is:

<rpc-reply
	xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="72">
	<rpc-error>
		<error-type>application</error-type>
		<error-tag>operation-failed</error-tag>
		<error-severity>error</error-severity>
		<error-message xml:lang="en">Data for both cases "disabled" and "manual-current" exist. (path "/czechlight-bidi-amp:narrow-1572/pump/control")</error-message>
	</rpc-error>
</rpc-reply>

...which means that the combination of the CLI and netopeer2 and sysrepo and libyang somehow do not implement semantics mandated in RFC 7950, section 7.9:

Since only one of the choice's cases can be valid at any time in the data tree, the creation of a node from one case implicitly deletes all nodes from all other cases. If a request creates a node from a case, the server will delete any existing nodes that are defined in other cases inside the choice.

I cannot rule out the possibility that we might be somehow abusing the candidate DS, though.

The quick hotfix is to use sysrepo-cli instead of netconf-cli-local. Doing that bypasses the NETCONF layer and talks directly to sysrepo (but still with the correct NACM bits).

Given that we're defaulting to netconf-cli-local for the unprivileged user's console, this might be a problem for the https://gerrit.cesnet.cz/q/topic:bidi-agc feature.