When I compile with confdc YANG modules that have deviation and\or augmentation and\or annotation:
which .fxs files should be located at the loadpath? only the .fxs of the main module or all of them?
Should I compile only the main module with flag of --deviation or the deviaiton file should be compiled as well?
what about augmentation files? they have any flag in the command line of compilation?
I will give specific example so it will be clearly. I have the following modules:
email@example.com - The standard module for ISIS
firstname.lastname@example.org - The deviation file for ietf-isis
email@example.com - The augmentation file for ietf-isis
firstname.lastname@example.org - The annotation file for ietf-isis
What should be compile and which command?
Which files should be copied to confd loadpath.
I compile the first module with the following command:
confdc -c --deviation email@example.com --fail-on-warnings -o firstname.lastname@example.org email@example.com
And I am getting the following error:
5-Sep-2017::17:04:19.814 rcohen1_Host1 confd: - The namespace urn:eci:params:xml:ns:yang:eci-interfaces-dev-npt1800 (referenced by urn:ietf:params:xml:ns:yang:ietf-interfaces) could not be found in the loadPath.
“The namespace urn:eci:params:xml:ns:yang:eci-interfaces-dev-npt1800 (referenced by urn:ietf:params:xml:ns:yang:ietf-interfaces) could not be found in the loadPath.\n”
When I compile firstname.lastname@example.org as well and put his .fxs in the loadpath it’s OK but according to your instructions only the main .fxs should be in the load path and not the .fxs of the deviation file.
This is the normal case, i.e. when your deviation module has only ‘deviation’ statements. However if it also has separate definitions, notably ‘typedef’, that are used by the deviations, you must also compile the deviation module and place it in the load path.
Thanks for your clarification. it solve the problem. indeed I had typedef in the deviated YANG module.
Can it be problematic to put always the deviated YANG modules in the loadpath?
Why do we have this limitation?
I assume that you use “limitation” to refer to the fact that you need the compiled deviation module in runtime if has separate definitions… I think it is pretty logical - compiling the target module with --deviation applies the ‘deviation’-statements from the deviation module, which effectively modify the target module. If one of those deviations makes the target module use a type that is defined in the deviation module, the deviation module needs to be present at runtime to provide the type definition, just like any other modules with type definitions used by the target module.