Non-backwards-compatible change silently breaks a script

[jfrahm]

We were testing some changes to the Cisco-IOS-XR-pim-cfg model. We changed a class name, which should not be backwards compatible.

When testing with the new API, we expected to see an error when running a test that uses the old syntax, but the script completed silently. YDK should validate that the user is not trying to add attributes to model objects that are not part of the model.

In our case, we changed 'Convergency' in the Cisco_IOS_XR_ipv4_pim model to 'ConvergenceTimeout' to be consistent with the CLI. When we tried to configure using the old syntax with the new API, no convergence-timeout config was added, but the script also did not throw any errors. YDK needs to throw errors in this case so we don't hide breakages in automation that use YDK.

[psykokwak4]

So the convergency is set using the old syntax and is ignored both by new YDK API and the device? In that case, maybe printing __slots__ for every class for YDK <= 0.5.4 could be used as an easy workaround.

[111pontes]

Not sure I fully understand the previous comment. Let me try to clarify. Assume a model with a container a and two int leafs b and c. An app makes use of the APIs generated for that model and implements:

a.b = 5
a.c = 10

Which results in the following XML encoding:

<a>
  <b>5</b>
  <c>10</c>
</a>

A new (non-backward compatible) version of the model is introduced which redefines container a as having two int leafs c and d. When the previous app is executed with the new API, b is silently ignored and the following XML encoding is generated:

<a>
  <c>10</c>
</a>

Since objects are expected to represent valid model data, validation should've raised an exception for the unexpected class attribute.

[psykokwak4]

Thanks for clarify. With the __slots__ attribute specified for the new API generated from new model, only c and d could be assigned, legally, in script. So the following statements will raise AttributeError:

a.b = 5   # b is an unexpected class attribute

To reproduce, try:

>>> class A(object):
...     __slots__ = ['c', 'd']
...
>>> a = A()
>>> a.c = 10
>>> a.d = 15
>>> a.b = 5
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'A' object has no attribute 'b'

Also note, the __slots__ attribute is only available for new style Python class(class inherited from object), so for the new Python classes(wrapper for libydk), it might need to change the parent for ydk.types.Entity from (ydk_.types.Entity) to (ydk_.types.Entity, object)to implement this behavior.

This behavior catches error as early as it can and happens before validation, if validation error but not attribute error is required, maybe its better to investigate other approaches.

[111pontes]

I see. You were suggesting __slots__ as a possible solution during API generation. I thought you were suggesting it as a user workaround :-) That approach should certainly catch the errors. It'd be good to investigate how this situation can be caught during data validation too and consider trade-offs between the different approaches.