yang-ext:mount allows a remote device to expose it's modules via RESTCONF. The controller will establish the mounted "capabilities" and then uses get-schema to load the module yang directly from the device.

This is very powerful, as it lets the controller, and it's RESTCONF NBI aggregate the capabilities from all managed devices as long as the device exports the yang for each.

The catch is that when RESTCONF POST is made such as :

http://server:8080/restconf/operations/opendaylight-inventory:/nodes/node/nameofnode/yang-ext:mount/modulename:rpcname

RestconfImpl current looks up the modulename in the global ControllerContext which doesn't have said modulename if it's unique to the device.

To make this concrete: The netopeer server has a toaster "capability" and today you can in fact issue a "make-toast" rpc on the "toaster" module via:

restconf/opendaylight-inventory:nodes/node/netopeer-config/yang-ext:mount/toaster:make-toast

However this only works if the "toaster" sample is configured on the controller. If it isn't, then this "toaster" capability isn't known to the controller and the RPC isn't considered valid.