Client-side validation of xr_shellutil_cfg.HostNames() in 0.7.0

[rikwade]

Issue tracker is ONLY used for reporting bugs. Please use the YDK Community for any support issues.

Expected Behavior

Sending incorrect type parameter returns: <class 'ydk.errors.YPYModelError'>

Current Behavior

Incorrect parameter returns: <class 'ydk.errors.YPYServiceProviderError'>

Steps to Reproduce

Send Int as parameter to xr_shellutil_cfg.HostNames.host_name rather than String

Your Script

from ydk.models.cisco_ios_xr import Cisco_IOS_XR_shellutil_cfg as xr_shellutil_cfg

new_hostname=xr_shellutil_cfg.HostNames()
new_hostname.host_name=-1

try:
    crud.update(provider,new_hostname)
except:
    print sys.exc_info()[0]

Logs

Enable logging and post the logs below

Executing CRUD update operation
=============Generating payload to send to device=============

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <target>
    <candidate/>
  </target>
  <error-option>rollback-on-error</error-option>
  <config><host-names xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-shellutil-cfg" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="merge">
  <host-name>-1</host-name>
</host-names>
</config>
</edit-config>
</rpc>


=============Reply payload received from device=============

<?xml version="1.0"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="25">
  <ok/>
</rpc-reply>



=============Executing commit=============

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <commit/>
</rpc>

=============Reply payload received from device=============

<?xml version="1.0"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="26">
  <rpc-error>
    <error-type>application</error-type>
    <error-tag>operation-failed</error-tag>
    <error-severity>error</error-severity>
    <error-path xmlns:ns1="http://cisco.com/ns/yang/Cisco-IOS-XR-shellutil-cfg">ns1:host-names/ns1:host-name</error-path>
    <error-message xml:lang="en">The process 'syslogd' rejected the operation but returned no error</error-message>
  </rpc-error>
</rpc-reply>



RPC error occurred: <?xml version="1.0"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="26">
  <rpc-error>
    <error-type>application</error-type>
    <error-tag>operation-failed</error-tag>
    <error-severity>error</error-severity>
    <error-path xmlns:ns1="http://cisco.com/ns/yang/Cisco-IOS-XR-shellutil-cfg">ns1:host-names/ns1:host-name</error-path>
    <error-message xml:lang="en">The process 'syslogd' rejected the operation but returned no error</error-message>
  </rpc-error>
</rpc-reply>

System Information

Python 2.7.14
YDK 0.7.0
Ubuntu 17.10
x86
XR: 6.1.4.16I

[ghost]

Hi @rikwade , as can be seen from the documentation, there is no restriction specified for the host_name field. The documentation is generated from the yang model. So in this case, the yang model has no restriction. Only if there is a restriction, YPYModelError is raised.

[rikwade]

Hi @abhikeshav, thank you for the information. The behaviour I was expecting was to receive a YPYModelError if an int was passed to a str field in the model. For example if I explicitly cast the parameter as an int with:

new_hostname.host_name=int(123456)

it is accepted and configured on the XR device. Thank you for clarifying the behaviour we should expect.

[ghost]

No problem, @rikwade. YPYModelError is only meant for checking the restrictions in the yang model. Python type checks for int instead of str is not part of this check.

[111pontes]

Thanks, @rikwade. We will look into enhancing this type of validation.

[111pontes]

Wonder why our automated testing didn't catch this issue. It seems we need to strengthen our type validation tests.

[rikwade]

@abhikeshav The confusing point is that the YANG model specifies hostname as a 'str'. So one may expect a client-side type check if a developer passes an 'int'.

The setting of a hostname is often used as a "YDK Hello World", and it is a good method of demonstrating client-side validation. Therefore if this simple example does not exhibit the expected behaviour then a more complex example needs to be used, such as setting a static route (which does exhibit the expected behaviour if an invalid IP address is passed as the parameter).

@111pontes It would be good to look at this validation.

[ghost]

Thanks. We will investigate into fixing this. @abhikeshav<https://github.com/abhikeshav> The confusing point is that the YANG model specifies hostname as a 'str'. So one may expect a client-side type check if a developer passes an 'int'. The setting of a hostname is often used as a "YDK Hello World", and it is a good method of demonstrating client-side validation. Therefore if this simple example does not exhibit the expected behaviour then a more complex example needs to be used, such as setting a static route (which does exhibit the expected behaviour if an invalid IP address is passed as the parameter). @111pontes<https://github.com/111pontes> It would be good to look at this validation. - You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#739 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AQTCR6XAeE1up_lXQTFRmGslm2bnNFdBks5tmshXgaJpZM4TIOtW>.

[ghost]

Fixed in #820