Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RPC output data should also be rendered as classes with proper validation #332

Closed
111pontes opened this issue Dec 13, 2016 · 5 comments
Closed

Comments

@111pontes
Copy link
Collaborator

Currently, the ExecutorService documentation indicates that the execute_rpc method doesn't return any value. However, many RPCs define output data. This method should return a validated entity for those RPCs.

@ghost ghost added the documentation label Dec 14, 2016
@111pontes 111pontes changed the title ExecutorService documentation inaccurate RPC output data should also be rendered as classes with proper validation Dec 16, 2016
@networkop
Copy link

+1 for this feature. Should it be possible to decode the received response manually in the meantime? With something like codec.decode(provider,xml)?

@ghost
Copy link

ghost commented Mar 25, 2017

Hi, this feature is being implemented in the new core infrastructure and will be available soon. In the meanwhile, yes, you can use the codec_service.decode function for decoding the returned XML payload

@111pontes
Copy link
Collaborator Author

111pontes commented Apr 19, 2017

I don't think Codec service can be seamlessly used. Returned string contains the raw NETCONF RPC reply. Even after manipulating the XML string to remove the rpc-reply tag, decoding still fails:

Traceback (most recent call last):
  File "./nc-execute-xr-ping-act-99-ydk.py", line 89, in <module>
    ping_rcp.output.ping_response = codec.decode(cd_provider, encoded_output)
  File "/usr/local/lib/python2.7/dist-packages/ydk/services/codec_service.py", line 49, in decode
    entity = self.operate_on_object_or_dictionary(payload, CodecService._decode_payload, [decoder])
  File "/usr/local/lib/python2.7/dist-packages/ydk/services/service.py", line 32, in operate_on_object_or_dictionary
    result = function(entity, *args)
  File "/usr/local/lib/python2.7/dist-packages/ydk/services/codec_service.py", line 55, in _decode_payload
    entity = decoder._decode(payload)
  File "/usr/local/lib/python2.7/dist-packages/ydk/providers/codec_provider.py", line 65, in _decode
    entity = self.decoder.decode(payload)
  File "/usr/local/lib/python2.7/dist-packages/ydk/providers/_decoder.py", line 40, in decode
    top_entity = self._get_top_entity(payload_tree)
  File "/usr/local/lib/python2.7/dist-packages/ydk/providers/_decoder.py", line 59, in _get_top_entity
    return self.get_top_container_for_namespace(namespace, root.tag.split('}')[1])
  File "/usr/local/lib/python2.7/dist-packages/ydk/providers/_decoder.py", line 51, in get_top_container_for_namespace
    entity_import = _yang_ns._namespace_package_map[(namespace, text)]
KeyError: ('http://cisco.com/ns/yang/Cisco-IOS-XR-ping-act', 'ping-response')

@ghost
Copy link

ghost commented May 25, 2017

For RPCs which don't define output data, like edit-config, which returns <ok/> on success, the return value would be None. Just want to make sure this makes sense.

@111pontes
Copy link
Collaborator Author

There are at least four possible scenarios:

  1. RPC succeeds and no data is returned and model specifies data (e.g. oper data non-existent)
  2. RPC succeeds, no data is returned and model specifies no data (e.g. RPC w/o output)
  3. RPC succeeds and data is returned
  4. RPC fails

Yes, it seems sensible that 1, 2 and 4 return None and exception handling is used to manage failure scenarios.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants