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

Issues with adding specific new yang models #4

Open
cfra opened this issue Oct 10, 2014 · 5 comments
Open

Issues with adding specific new yang models #4

cfra opened this issue Oct 10, 2014 · 5 comments
Assignees

Comments

@cfra
Copy link

cfra commented Oct 10, 2014

I encountered some issues while trying to add the ietf-routing yang model and the is-is yang model from draft-litkowski-netmod-isis-cfg-00. You can find the particular yang files here:
https://raw.githubusercontent.com/cfra/mand/master/yang/specs/[email protected]
https://raw.githubusercontent.com/cfra/mand/master/yang/specs/[email protected]
https://raw.githubusercontent.com/cfra/mand/master/yang/specs/[email protected]
https://raw.githubusercontent.com/cfra/mand/master/yang/specs/[email protected]

Trying to add these files, I get the following error output from the pyang invocation that happens as part of the build process:
pyang --plugindir ../yang/pyang_plugin/ -p ../yang/specs -f OpenCPE ../yang/specs/.yang
Traceback (most recent call last):
File "/usr/local/bin/pyang", line 333, in
run()
File "/usr/local/bin/pyang", line 318, in run
emit_obj.emit(ctx, modules, fd)
File "../yang/pyang_plugin/OpenCPE.py", line 40, in emit
emit_tree(modules, fd)
File "../yang/pyang_plugin/OpenCPE.py", line 124, in emit_tree
print_children(chs, module, typedefs, groupings, augments, deviations, annotations, fd)
File "../yang/pyang_plugin/OpenCPE.py", line 196, in print_children
print_node(ch, module, typedefs, groupings, augments, deviations, annotations, fd, child_write_access)
File "../yang/pyang_plugin/OpenCPE.py", line 203, in print_node
print_children(chs, module, typedefs, groupings, augments, deviations, annotations, fd, write_access)
File "../yang/pyang_plugin/OpenCPE.py", line 196, in print_children
print_node(ch, module, typedefs, groupings, augments, deviations, annotations, fd, child_write_access)
File "../yang/pyang_plugin/OpenCPE.py", line 203, in print_node
print_children(chs, module, typedefs, groupings, augments, deviations, annotations, fd, write_access)
File "../yang/pyang_plugin/OpenCPE.py", line 196, in print_children
print_node(ch, module, typedefs, groupings, augments, deviations, annotations, fd, child_write_access)
File "../yang/pyang_plugin/OpenCPE.py", line 203, in print_node
print_children(chs, module, typedefs, groupings, augments, deviations, annotations, fd, write_access)
File "../yang/pyang_plugin/OpenCPE.py", line 196, in print_children
print_node(ch, module, typedefs, groupings, augments, deviations, annotations, fd, child_write_access)
File "../yang/pyang_plugin/OpenCPE.py", line 229, in print_node
fd.write(2_tab + "{ .flags = IDX_UNIQUE, .type = " + c_types[key_leafs[key.arg]] + ", .element = " + "field
" + name + "_" + key.arg + " },\n")
KeyError: 'address-family'

@skattelmann
Copy link

Hi,
I'm currently working on this and already fixed your the above issue. Further problems are related to naming conventions. Also the ipv4 and ipv6 model provoke naming clashes. I'll need to find a workaround here.

@skattelmann
Copy link

I pushed a branch named "isis_fix". This branch compiles clean for the unicast and routing files (not the isis file). But some data nodes are still missing.

@skattelmann
Copy link

Ok, i also pushed the isis model and everything is compiling. Please tell us when here if you see missing nodes from the data model.

@cfra
Copy link
Author

cfra commented Oct 27, 2014

Thank you for working on this. I am currently doing some tests with it and will let you know how it turns out.
Looking at the changelog, I see that you modified the ietf-ipv4-unicast-routing and the ietf-ipv6-unicast-routing model. From my understanding, if I expose the current model via NetCONF, a netconf client expecting us to follow the ietf-ipv6/ipv4-unicast model won't work correctly with those changes in place, would it?

@skattelmann
Copy link

The clients will be based on these yang models anyway. So this is no problem. I made these small name changes because the code generator "flattens" the data structure, e.g. to consider both the ipv4 and -6 case at the same time. You can also see this in 'choices'. These 'destination-prefix' nodes I changed are augmented to another node with the same name what the generator cannot handle (without identifying every node with an own id).

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

No branches or pull requests

2 participants