mbj4668/pyang

An extensible YANG validator and converter in python

pyang's Issues

pprint fails when printing unknown statements

When pprint encounter an unknown statement, it fails with the following error:

  File "/srv/home/hshibuya/playground/pyang-unknown/pyang/statements.py",
line 2197, in pprint
    x.pprint(indent + ' ', f)
  File "/srv/home/hshibuya/playground/pyang-unknown/pyang/statements.py",
line 2193, in pprint
    x.pprint(indent + ' ', f)
  File "/srv/home/hshibuya/playground/pyang-unknown/pyang/statements.py",
line 2189, in pprint
    print indent + self.keyword + " " + self.arg
TypeError: cannot concatenate 'str' and 'tuple' objects

Attached a patch to invoke util.keyword_to_str to avoid this problem.

Original issue reported on code.google.com by [email protected] on 26 May 2010 at 7:49

Attachments:

• statements.patch

Augmentation applied to a submodule's node - problem with uniqueness of node identifiers

I define a module and its submodule. At the top-level of the
submodule I define a container node which contains a leaf with the name
'ifType'. Then by using the 'augment' statement from the module, I add to
the container one more leaf with the same name. As a result, the container
contains two nodes with the same name, but pyang consider it to be correct.
Please, find the test case's files attached.

What version of the product are you using? On what operating system?
pyang 0.9.3

Original issue reported on code.google.com by [email protected] on 18 Apr 2009 at 11:08

Attachments:

• augment-super.yang
• augment.yang

Problem with uniqueness of the type identifiers within one namespace

According to the specification:
All derived type names defined within a parent node or at the top-level of
the module or its submodules share the same type identifier namespace. 
This namespace is scoped to the parent node or module. All identifiers
defined in a namespace MUST be unique.

I define a module and its submodule. At the top-level of the module and the
submodule I declare types with the same name. So, according to the
specification they share the same namespace. Since it's not allowed to
define types with the same name within one namespace, the validation of the
module should end up with an error. But while validating such a test case,
pyang consider it to be correct. Please, find test case files attached.


What version of the product are you using? On what operating system?
pyang 0.9.3

Original issue reported on code.google.com by [email protected] on 16 Apr 2009 at 1:46

Attachments:

• composite.yang
• submodule.yang

Error occurs while augmenting a node created by instantiation of a grouping

When run pyang on the attached example the result is the following error:

Traceback (most recent call last):
  File "/usr/local/bin/pyang", line 190, in <module>
    run()
  File "/usr/local/bin/pyang", line 141, in run
    module = ctx.add_module(filename, text)
  File "/usr/local/lib/python2.6/dist-packages/pyang/__init__.py", line 64,
in add_module
    return self.add_parsed_module(module)
  File "/usr/local/lib/python2.6/dist-packages/pyang/__init__.py", line 92,
in add_parsed_module
    statements.validate_module(self, module)
  File "/usr/local/lib/python2.6/dist-packages/pyang/statements.py", line
79, in validate_module
    iterate(module, phase)
  File "/usr/local/lib/python2.6/dist-packages/pyang/statements.py", line
74, in iterate
    iterate(s, phase)
  File "/usr/local/lib/python2.6/dist-packages/pyang/statements.py", line
37, in iterate
    res = f(ctx, stmt)
  File "/usr/local/lib/python2.6/dist-packages/pyang/statements.py", line
174, in <lambda>
    ('expand_2', 'augment'):lambda ctx, s: v_expand_2_augment(ctx, s),
  File "/usr/local/lib/python2.6/dist-packages/pyang/statements.py", line
1316, in v_expand_2_augment
    if (stmt.i_target_node.i_config == False and
AttributeError: 'Statement' object has no attribute 'i_config'

Original issue reported on code.google.com by [email protected] on 18 Feb 2010 at 10:43

Attachments:

• augment-issue.yang

Typo "chocie" in plugins/tree.py

chocie -> choice.

Original issue reported on code.google.com by [email protected] on 7 Jul 2010 at 12:55

Attachments:

• tree.py.patch

unknown statements not included from submodule

Not so sure if this is language question or pyang question.  

I defined an extension, "abbreviate", to define a pair of words
for name abbreviation for the purpose of code generation.  i.e.

myns:abbreviate "system sys"
myns:abbreviate "connection conn"

From my plugin, I can access those with "search" methods of "statements"
class and it is working as I expected.

Now, since those are not fundamental part of the data model, I want to move
it out of the way to a submodule.  But if I move those to submodule, those
are not merged into main modules tree when included.  

I couldn't find in the draft if the handling of those unknown statements
are clearly defined.  Do you think those should be merged into main tree? 
If not, why not?

Original issue reported on code.google.com by [email protected] on 12 May 2010 at 3:13

"dump" format

How about "dump" format plugin which simply invoke pprint on each module?  
I find it useful for debugging. 

Original issue reported on code.google.com by [email protected] on 27 May 2010 at 1:02

Attachments:

• dump.py

syntax error with min-elements not caught

What steps will reproduce the problem?
1. Module test.yang:
module test {
    min-elements 1;
}
2. Run "pyang test.yang" 

What is the expected output? What do you see instead?
YANG syntax error should be reported. A Python KeyError occurs instead:

Traceback (most recent call last):
  File "/home/lhotka/bin/pyang", line 161, in <module>
    run()
  File "/home/lhotka/bin/pyang", line 135, in run
    module = ctx.add_module(filename, text)
  File "/home/lhotka/lib/Python/pyang/__init__.py", line 56, in add_module
    self._set_attrs(module)
  File "/home/lhotka/lib/Python/pyang/__init__.py", line 133, in _set_attrs
    util.attrsearch(s.arg, 'arg', stmt.__dict__[attr])):
KeyError: 'min_elements'


Please use labels and text to provide additional information.

Original issue reported on code.google.com by [email protected] on 17 Jun 2008 at 1:05

If the target node is in another module, then nodes added by the augmentation MUST NOT be mandatory nodes

In Section 7.15. "The augment Statement" of the draft there is a statement:

"If the target node is in another module, then nodes added by the
augmentation MUST NOT be mandatory nodes (see Section 3.1)."

It seems that in the current version of pyang there is no such validation.
See the attached examples. The module ns2 augments the container "c" in the
module ns1 by adding a couple of mandatory nodes. But pyang does not report
these errors.

Original issue reported on code.google.com by [email protected] on 20 Feb 2010 at 11:25

Attachments:

• ns1.yang
• ns2.yang

Remove empty RPC input/ouput nodes in pyang -f tree

I think it's kind of distracting that empty and not existing input or output 
nodes in RPCs are shown in treeview. 
Or is this wanted behavior? 

Original issue reported on code.google.com by [email protected] on 30 Aug 2010 at 3:37

In XPath, prefixes not added to node names matching operators.

The translation of XPath expressions performed by the DSDL plugin doesn't
do syntactic analysis. Consequently, prefixes are not added to node names
that match XPath operator keywords "and", "or", "div" and "mod".

For example, the valid XPath expression "or and and" is not changed by the
translation although the correct result should be "PREFIX:or and PREFIX:and".

Before this is fixed, node names matching the operator keywords must have
an explicit prefix in YANG 'must' and 'when' statements.

Original issue reported on code.google.com by [email protected] on 26 May 2010 at 9:11

Circular groupings - pyang hangs

What steps will reproduce the problem?
While running pyang on the attached example it goes into infinite loop.

What is the expected output? What do you see instead?
There is a circular dependency.

What version of the product are you using? On what operating system?
pyang 0.9.3

Original issue reported on code.google.com by [email protected] on 18 Apr 2009 at 12:34

Attachments:

• infinite-loop.yang

Mandatory nodes directly under the default case in the choice

What steps will reproduce the problem?
According to the specification:
"There MUST NOT be any mandatory nodes (Section 3.1) directly under the
default case of the choice".

In the attached example I added a leaf with 'mandatory' true under the
default case, and pyang does not complain about this.

What version of the product are you using? On what operating system?
pyang 0.9.3

Original issue reported on code.google.com by [email protected] on 20 Apr 2009 at 8:20

Attachments:

• list2.yang

cryptic error message

This error message exposes internal structures that may confuse users:

auggr.yin:8: error: prefix "at" already used for module (u'auggr', None)

Only the module name should appear:

auggr.yin:8: error: prefix "at" already used for module "auggr"

Original issue reported on code.google.com by [email protected] on 3 Jun 2010 at 8:11

Collision of type's identifiers after applied 'uses' statement

According to the specification:
'The effect of a "uses" reference to a grouping is that the nodes defined
by the grouping are copied into the current schema tree'.

So, if I get it correctly, in the example below after the statement 'uses
testGrouping;' is processed, we will have a collision of identifiers
'type1'. But pyang finds it correct.

module grouping 
{
    namespace "urn:test";
    prefix grop;

    container container1 {
    typedef type1 {
        type string;
    }
    }

    uses testGrouping;

    grouping testGrouping {
        typedef type1 {
        type string;
    }
    }
}

What version of the product are you using? On what operating system?
pyang 0.9.3

Original issue reported on code.google.com by [email protected] on 18 Apr 2009 at 6:40

Attachments:

• grouping.yang

child of read-only parent can not be writable

What steps will reproduce the problem?
1. mark parent node "config false".
2. mark child node "config true".

What is the expected output? What do you see instead?
The parent node should be "ro" in treeview, childnode should be "rw".
Instead, the child node is "ro", too. 

What version of the product are you using? On what operating system?
Latest SVN checkout, revision 405.
Linux 2.6.32-22-generic #35-Ubuntu SMP Tue Jun 1 14:18:25 UTC 2010 x86_64
GNU/Linux.

Original issue reported on code.google.com by [email protected] on 3 Jun 2010 at 12:35

manpage build fails on redhat

This is can of worm but new docbook to manpage conversion fails on
Redhat/Fedora because they install manpage/docbook.xsl in different
location (/usr/share/sgml/docbook/xsl-stylesheets/manpages/docbook.xsl). I
looked into python distutil but it is not helpful in this aspect.

Here is a quick and dirty patch to the doc/Makefile if you may.

Original issue reported on code.google.com by [email protected] on 11 May 2010 at 8:37

Attachments:

• doc-makefile.patch

XPath parser adds namespace to keywords

New XPath parser adds namespace to XPath operators such as "and".

Original issue reported on code.google.com by [email protected] on 10 Jul 2009 at 7:10

Execution ends up with a runtime error

What steps will reproduce the problem?
While running pyang on the attached example a runtime error occurs. The
grammar of the test case is not correct. The 'uses' statement is used under
the 'leaf'.

What do you see instead?
Traceback (most recent call last):
  File "/usr/bin/pyang", line 186, in <module>
    run()
  File "/usr/bin/pyang", line 139, in run
    module = ctx.add_module(filename, text)
  File "/usr/lib/python2.5/site-packages/pyang/__init__.py", line 44, in
add_module
    module = self._add_module(ref, text, format)
  File "/usr/lib/python2.5/site-packages/pyang/__init__.py", line 83, in
_add_module
    statements.validate_module(self, module)
  File "/usr/lib/python2.5/site-packages/pyang/statements.py", line 76, in
validate_module
    iterate(module, phase)
  File "/usr/lib/python2.5/site-packages/pyang/statements.py", line 39, in
iterate
    res = f(ctx, stmt)
  File "/usr/lib/python2.5/site-packages/pyang/statements.py", line 158, in
<lambda>
    ('expand_1', 'module'):lambda ctx, s: v_expand_1_children(ctx, s),
  File "/usr/lib/python2.5/site-packages/pyang/statements.py", line 910, in
v_expand_1_children
    v_expand_1_children(ctx, s)
  File "/usr/lib/python2.5/site-packages/pyang/statements.py", line 908, in
v_expand_1_children
    v_expand_1_children(ctx, s)
  File "/usr/lib/python2.5/site-packages/pyang/statements.py", line 905, in
v_expand_1_children
    v_expand_1_uses(ctx, s)
  File "/usr/lib/python2.5/site-packages/pyang/statements.py", line 916, in
v_expand_1_uses
    if stmt.i_grouping is None:
AttributeError: 'Statement' object has no attribute 'i_grouping'

What version of the product are you using? On what operating system?
pyang 0.9.3

Original issue reported on code.google.com by [email protected] on 18 Apr 2009 at 12:19

Attachments:

• cyclic-groupings.yang

Pyang does not find files that are named like recommended in ietf draft.

What steps will reproduce the problem?
1. import yang module
2. name imported yang module as recommended in
draft-ietf-netmod-yang-12/5.2 File Layout (with '@-YYYY-MM-DD')
3. run pyang

Pyang should find and validate the file. Instead an error is thrown:
"<ImportingModule>.yang:7: error: module "ietf-yang-types" not found in
search path".

Pyang 1.0a on 
Linux 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:28:05 UTC 2010 x86_64
GNU/Linux

Original issue reported on code.google.com by [email protected] on 31 May 2010 at 2:21

Parsing problem with the 'unknown-statement'

According to the specification, the grammar rule for the unknown-statement
looks in the following way:

   unknown-statement   = prefix ":" identifier [sep string] optsep
                         (";" / "{" *unknown-statement "}")

where a separator is required after the identifier if the argument string
is present. But in pyang this separator is optional. For example such a
test case is valid, but 'ext:ext' and ':separator' are not separated:

module "extension"
{
    namespace "urn:test:ext";
    prefix ext; 

        ext:ext:separator;

    extension ext {
        argument test;
        status current;
    }
}

What version of the product are you using? On what operating system?
pyang 0.9.3

Original issue reported on code.google.com by [email protected] on 17 Apr 2009 at 2:34

Attachments:

• ext.yang

DSDL: Schematron assert for unique is wrong

Reported by James Piper:

We think there is a bug in the pyang handling of the unique statement: 

preceding-sibling::n:host[n:hostname != current()/n:hostname]

does not seem to work. 

We think it should read:

count(preceding-sibling::n:host[n:hostname = current()/n:hostname])=0

Original issue reported on code.google.com by [email protected] on 10 Dec 2008 at 10:18

residual issues with pyang -f xsd ietf-netconf-state

What steps will reproduce the problem?
1. take output from pyang -f xsd ietf-netconf-state.yang
2.run through xjc to create JAXB code bindings
3. parse issues appear

What is the expected output? What do you see instead?
expected output is the set of JAXB code binding classes

what is seen:
./run_xjc_netconf_monitoring.sh 
parsing a schema...
[ERROR] src-resolve: Cannot resolve the name 'identityref' to a(n) 'type
definition' component.
  line 334 of
file:/home/ellison/workspace-netconf/netconf/yang/netconf-monitoring-4.xsd

[ERROR] src-resolve: Cannot resolve the name 'identityref' to a(n) 'type
definition' component.
  line 401 of
file:/home/ellison/workspace-netconf/netconf/yang/netconf-monitoring-4.xsd

[ERROR] src-resolve: Cannot resolve the name 'identityref' to a(n) 'type
definition' component.
  line 559 of
file:/home/ellison/workspace-netconf/netconf/yang/netconf-monitoring-4.xsd

[ERROR] cos-nonambig: WC[##other:"urn:ietf:params:xml:ns:netconf:state"]
and WC[##other:"urn:ietf:params:xml:ns:netconf:state"] (or elements from
their substitution group) violate "Unique Particle Attribution". During
validation against this schema, ambiguity would be created for those two
particles.
  line 167 of
file:/home/ellison/workspace-netconf/netconf/yang/netconf-monitoring-4.xsd

[ERROR] cos-nonambig: WC[##other:"urn:ietf:params:xml:ns:netconf:state"]
and WC[##other:"urn:ietf:params:xml:ns:netconf:state"] (or elements from
their substitution group) violate "Unique Particle Attribution". During
validation against this schema, ambiguity would be created for those two
particles.
  line 207 of
file:/home/ellison/workspace-netconf/netconf/yang/netconf-monitoring-4.xsd

Failed to parse a schema.


What version of the product are you using? On what operating system?

latest from svn, fedora 11.

Please provide any additional information below.

For the 'identityref' name, I am wondering if xs:IDREF would be the correct
output.

for the non-ambiguous ## other issues, I am wondering if pyang is emitting
too many xs:any elements as commenting out some of these removes the parse
error.

Original issue reported on code.google.com by [email protected] on 6 Oct 2009 at 4:59

The parser allows "mandatory true" and default together on choice nodes

This is forbidden in sec. 7.9.3 of YANG draft

Original issue reported on code.google.com by [email protected] on 27 Apr 2009 at 1:35

In XSD, a leafref should get the type of the target, not xs:string

The following module:
module a {
  prefix a;
  namespace 'urn:a';

  leaf a {
    type int32;
  }

  leaf b {
    type leafref {
      path "/a";
    }
  }
}

gives:

  <xs:element name="b">
    <xs:simpleType>
      <xs:restriction base="xs:string">
      </xs:restriction>
    </xs:simpleType>
  </xs:element>

it should be:

  <xs:element name="b">
    <xs:simpleType>
      <xs:restriction base="xs:int">
      </xs:restriction>
    </xs:simpleType>
  </xs:element>

Original issue reported on code.google.com by [email protected] on 10 Mar 2010 at 7:59

dependency on libxml2

pyang depends on libxml2, but only through types.py, and it is only used
for validating regex patterns in the string type. This dependency should be
eventually removed.

Original issue reported on code.google.com by [email protected] on 12 May 2010 at 2:09

Key leafs in a list must have the same value for their "config" as the list itself.

What steps will reproduce the problem?
According to the specification:
"All key leafs in a list MUST have the same value for their "config" as the
list itself."

In the attached example I use leafs with different "config" values in the
key and it is still correct.

What version of the product are you using? On what operating system?
pyang 0.9.3

Original issue reported on code.google.com by [email protected] on 20 Apr 2009 at 8:35

Attachments:

• lists.yang

pyang abends when trying to translate from YANG to XSD

What steps will reproduce the problem?

1. get the ietf-netconf YANG module contained in
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-netconf-4741bis-01.
txt

2. run pyang ietf-inet-types.yang ietf-netconf.yang
no errors reported.

3. run pyang -f xsd  -o ietf-netconf.xsd ietf-netconf.yang

What is the expected output? What do you see instead?

expect to see XSD output, instead saw:
Traceback (most recent call last):
  File "/usr/bin/pyang", line 186, in <module>
    run()
  File "/usr/bin/pyang", line 180, in run
    emit_obj.emit(ctx, module, fd)
  File "/usr/lib/python2.6/site-packages/pyang/translators/xsd.py", line
151, in emit
    emit_xsd(ctx, module, fd)
  File "/usr/lib/python2.6/site-packages/pyang/translators/xsd.py", line
270, in emit_xsd
    pre = "p" + i
TypeError: cannot concatenate 'str' and 'int' objects


What version of the product are you using? On what operating system?

pyang 0.9.3 on fedora 11 64 bit

Please provide any additional information below.

running pyang -f yin  -o ietf-netconf.yin ietf-netconf.yang works,
but then running pyang -f xsd  -o ietf-netconf.xsd ietf-netconf.yin
incurs the same output as above

Original issue reported on code.google.com by [email protected] on 5 Oct 2009 at 5:16

Error occurs while augmenting a node with config value "false" created by instantiation of a grouping

The following error occurs when I run pyang on the attached example:

Traceback (most recent call last):
  File "/usr/local/bin/pyang", line 190, in <module>
    run()
  File "/usr/local/bin/pyang", line 141, in run
    module = ctx.add_module(filename, text)
  File "/usr/local/lib/python2.6/dist-packages/pyang/__init__.py", line 64,
in add_module
    return self.add_parsed_module(module)
  File "/usr/local/lib/python2.6/dist-packages/pyang/__init__.py", line 92,
in add_parsed_module
    statements.validate_module(self, module)
  File "/usr/local/lib/python2.6/dist-packages/pyang/statements.py", line
79, in validate_module
    iterate(module, phase)
  File "/usr/local/lib/python2.6/dist-packages/pyang/statements.py", line
37, in iterate
    res = f(ctx, stmt)
  File "/usr/local/lib/python2.6/dist-packages/pyang/statements.py", line
166, in <lambda>
    ('expand_1', 'module'):lambda ctx, s: v_expand_1_children(ctx, s),
  File "/usr/local/lib/python2.6/dist-packages/pyang/statements.py", line
1085, in v_expand_1_children
    v_expand_2_augment(ctx, a)
  File "/usr/local/lib/python2.6/dist-packages/pyang/statements.py", line
1327, in v_expand_2_augment
    c.i_config == True):
AttributeError: 'Statement' object has no attribute 'i_config'

Original issue reported on code.google.com by [email protected] on 18 Feb 2010 at 11:49

Attachments:

• issue.yang

leafref via a derived type doesn't work

$ cat ll-leafref.yang
module ll-leafref {
  namespace "http://example.com/ll/leafref";
  prefix lr;
  list seq {
    key "clef";
    leaf clef {
      type string;
    }
  }
  leaf lref {
    type myleafref;
  }
  typedef myleafref {
    type leafref {
      path "/seq/clef";
    }
    default "bar";
  }
}

$ pyang ll-leafref.yang
Traceback (most recent call last):
  File "/home/lhotka/bin/pyang", line 239, in <module>
    run()
  File "/home/lhotka/bin/pyang", line 160, in run
    module = ctx.add_module(filename, text)
  File "/home/lhotka/lib/python/pyang/__init__.py", line 68, in add_module
    return self.add_parsed_module(module)
  File "/home/lhotka/lib/python/pyang/__init__.py", line 96, in add_parsed_module
    statements.validate_module(self, module)
  File "/home/lhotka/lib/python/pyang/statements.py", line 90, in validate_module
    iterate(module, phase)
  File "/home/lhotka/lib/python/pyang/statements.py", line 79, in iterate
    iterate(s, phase)
  File "/home/lhotka/lib/python/pyang/statements.py", line 48, in iterate
    res = f(ctx, stmt)
  File "/home/lhotka/lib/python/pyang/statements.py", line 195, in <lambda>
    ('reference_2', 'leaf'):lambda ctx, s:v_reference_leaf_leafref(ctx, s),
  File "/home/lhotka/lib/python/pyang/statements.py", line 1621, in v_reference_leaf_leafref
    path_type_spec.path, path_type_spec.pos)
  File "/home/lhotka/lib/python/pyang/statements.py", line 2174, in validate_leafref_path
    expanded_path = stmt.search_one('type').search_one('path').arg
AttributeError: 'NoneType' object has no attribute 'arg'

Original issue reported on code.google.com by [email protected] on 16 Jun 2010 at 8:21

[deleted issue]

[deleted issue]

deviation - replace - runtime error occurs

There is a minor problem in the code of the v_reference_deviate() function.
Please the attached example. In order to fix the problem, 

[line = 1633]                 idx = t.substmts(old)

should be replaced to 

[line = 1633]                 idx = t.substmts.index(old)

Original issue reported on code.google.com by [email protected] on 12 Mar 2010 at 10:46

Attachments:

• deviations.yang

Incorrect validation of the YANG definition.

The following YANG definitions validated correctly by the pyang:

module test3 {
  namespace "http://test3.com";
  prefix test3;

  extension substatement {
    argument name;
  }

  extension arg-type {
    test3:substatement "type";
  }

  extension qualifier {
    argument name {
      test3:arg-type {
        type enumeration {
          enum 1;
          enum 2;
          enum 3;
        }
      }
    }
  }
}

But in fact, according to the YANG ABNF grammar
(http://tools.ietf.org/html/draft-ietf-netmod-yang-02#page-132) it is not
correct. Argument statement cannot include definition of the type enumeration.

Original issue reported on code.google.com by [email protected] on 19 Mar 2010 at 12:47

bogus duplicate leaf

$ pyang testa.yang
testa.yang:12 (at testa.yang:8): error: there is already a child node to
"g" at testa.yang:7 with the name "a" defined at testa.yang:12 (at
testa.yang:8)
testa.yang:12: error: there is already a child node to "outer" at
testa.yang:6 with the name "a" defined at testa.yang:12 (at testa.yang:8)

The attached module seems correct though. If "container outer" is at the
top level of the module, i.e. not inside an rpc, the error doesn't appear. 

Original issue reported on code.google.com by [email protected] on 12 May 2010 at 2:33

Attachments:

• testa.yang

Problem with 'input' and output statements' grammar

input-stmt             = input-keyword optsep 
                         "{" stmtsep 
                             ;; these stmts can appear in any order 
                             *((typedef-stmt /  grouping-stmt) stmtsep) 
                             1*(data-def-stmt stmtsep) 
                         "}" 

So, the cardinality of the 'data-def-stmt' statement must be at least one.
pyang allows to define input statements without a data definition
statement. The test case is attached.

Original issue reported on code.google.com by [email protected] on 20 Apr 2009 at 9:58

Attachments:

• rpc.yang

error messages are not defined

Error messages are not defined for the following error codes used in the
statements.py:

BAD_DEVIATE_ADD 
BAD_DEVIATE_TYPE
BAD_DEVIATE_DEL

Original issue reported on code.google.com by [email protected] on 12 Mar 2010 at 10:38

Type identifier namespace

Probably I have a problem with understanding of the specification
draft-ietf-netmod-yang-05.

The specification says:
* All derived type names defined within a parent node or at the top-     
level of the module or its submodules share the same type identifier
namespace.  This namespace is scoped to the parent node or module.

If I get it correctly, the following example should be considered as valid:
module type-uniqueness
{
    namespace "urn:test";
    prefix u1;

    container interface2 {
    typedef str1 {
        type string;
    }
    container interface2 {
        typedef str1 {
        type string;
        }
    }
    } 
}

Because both types are defined within different parent nodes and not at the
top-level of the module, i.e. the type identifiers belong to different
identifier namespaces. But pyang considers this as a collision.

If I the namespace for types is really defined in this way, then the
example should be invalid:

module type-uniqueness
{
    namespace "urn:test";
    prefix u1;

    container interface2 {
    typedef str1 {
        type string;
    }
    container interface2 {
        typedef str2 {
        type str1;
        }
    }
    } 
}

Because the second type definition is out of the 'str1' type scope. 

Original issue reported on code.google.com by [email protected] on 8 May 2009 at 9:36

Attachments:

• type-uniquenesee.yang
• types.yang

Different behaviours for YANG and YIN syntaxes

pyang sometimes behaves differently for YANG and YIN versions of the same 
module. This happens for the YIN version of issue 46 (modules are attached):

$ pyang prefclash.yin
...
  File "/home/lhotka/lib/python/pyang/__init__.py", line 146, in _ensure_revs
    module = p.parse(self, ref, text)
  File "/home/lhotka/lib/python/pyang/yin_parser.py", line 98, in parse
    self.look_ahead()
  File "/home/lhotka/lib/python/pyang/yin_parser.py", line 276, in look_ahead
    mod = self.ctx.search_module(ch.pos, modname)
  File "/home/lhotka/lib/python/pyang/__init__.py", line 186, in search_module
    (revision, handle) = self._get_latest_rev(self.revs[modulename])
  File "/home/lhotka/lib/python/pyang/__init__.py", line 116, in _get_latest_rev
    self._ensure_revs(revs)
  File "/home/lhotka/lib/python/pyang/__init__.py", line 146, in _ensure_revs
    module = p.parse(self, ref, text)
  File "/home/lhotka/lib/python/pyang/yin_parser.py", line 89, in parse
    self.parser.Parse(text, True)
  File "/home/lhotka/lib/python/pyang/yin_parser.py", line 114, in start_element
    e = Element(ns, local_name, attrs, self.pos)
RuntimeError: maximum recursion depth exceeded

To prevent this entirely, it would be better to parse both YANG and YIN into a 
common format first, caring just about syntax, and only then perform any other 
checks.

It would be useful to be able to perform the YANG<->YIN conversion even if the 
source module contains semantic errors (perhaps on demand).  

Original issue reported on code.google.com by [email protected] on 24 Jun 2010 at 7:41

Attachments:

• prefclash.yin
• prefclashx.yin

AttributeError: 'Position' object has no attribute 'top'

I checked out the latest version before commenting on Issue 40 again. When
I now start pyang with my YANG-module(s) i get the following Error: 

Traceback (most recent call last):
  File "<homedir>/pyang/pyang-read-only/bin/pyang", line 234, in <module>
    run()
  File "<homedir>/pyang/pyang-read-only/bin/pyang", line 191, in run
    if (hasattr(epos.top, 'i_modulename') and
AttributeError: 'Position' object has no attribute 'top'

Original issue reported on code.google.com by [email protected] on 7 Jun 2010 at 3:25

Signalling unavailable features

A new command-line parameter should be added to yang2dsdl to signal YANG 
features that are not available. The switch could be -f and its value will be 
in the form

-f modname:feature1,feature2,...

This can be used multiple times for features defined in different modules.

Original issue reported on code.google.com by [email protected] on 28 Jul 2010 at 11:57

Circular import is sometimes undetected

Circular import of modules is sometimes not detected. The two modules below are 
completely symmetrical but circular dependency is only reported for prefclashx:

module prefclash {
  namespace "http://prefclash";
  prefix a;
  import prefclashx {
    prefix a1;
  }
  leaf a {
    must "/a1:a < .";
    type uint8;
  }
}
$ cat prefclashx.yang 
module prefclashx {
  namespace "http://prefclashx";
  prefix a;
  import prefclash {
    prefix a1;
  }
  leaf a {
    must "/a1:a > .";
    type uint8;
  }
}
$ pyang prefclash.yang 
$ pyang prefclashx.yang 
prefclash.yin:7: error: circular dependency for module "prefclashx"

Original issue reported on code.google.com by [email protected] on 24 Jun 2010 at 7:09

Type identifier collision in the submodules of the module

I am not sure whether it's an issue or it is correct behavior. I have a module:

module composite {
    namespace "urn:composite";
    prefix c;

    include submod1 {
    }    

    include submod2 {
    }    

}

which is splitted into 2 submodules:

submodule submod1 {
    belongs-to composite {
        prefix mod1;
    }

    typedef t1 {
        type string;
    }
}

and 

submodule submod2 {

    belongs-to composite {
        prefix mod;
    }

    container new {
    typedef t1 {
        type string;
    }
    }
}

In the submodule 'submod1' I define the top level type 't1' and then I try
to define the type with the same name (but not the top level type) in the
submodule 'submod2'. PYANG does not complain about this. Is it correct or
it also breaks identifier uniqueness?

Original issue reported on code.google.com by [email protected] on 27 Apr 2009 at 8:22

Attachments:

• composite.yang
• submod1.yang
• submod2.yang

Problem with the 'augment' statement

At first I define a submodule as follows:

submodule augment {
  belongs-to augment-super {
    prefix "as";
  }
  container interfaces {
    list ifEntry {
       key "ifIndex";
       leaf ifIndex {
         type int32;
       }
    }
  }
}                                                                         


Then, from the module which includes that submodule I want to augment the
ifEntry list:

module augment-super {
  namespace "urn:test";
  prefix "as";

  include augment;

  augment "/as:interfaces/as:ifEntry" {
    leaf someNode {
      type string;
    }
  }
}

Everything seems to be correct with the module and submodule, but pyang
indicates the following errors:

augment-super.yang:7: error: there is already a child node to "interfaces"
at augment.yang:6 with the name "ifEntry" defined at augment.yang:7
augment-super.yang:7: error: node augment-super::ifEntry is not found

Original issue reported on code.google.com by [email protected] on 25 Apr 2009 at 9:00

Attachments:

• augment.yang
• augment-super.yang

DSDL translator crashes when submodules are used

What steps will reproduce the problem?
Using slightly modified acme-system and acme-types examples from the
Internet Draft. See attachments. Checking that DSDL is generated correctly
when a grouping from a submodule is used.

What is the expected output? What do you see instead?
XSD generates correctly, but DSDL translator crashes. See attachments.

What version of the product are you using? On what operating system?
0.9.3 on Ubuntu 8.10

Please provide any additional information below.

James Piper.

Original issue reported on code.google.com by [email protected] on 2 Feb 2009 at 3:49

Attachments:

• acme-system.yang
• acme-types.yang
• out.xsd
• out.dsdl

pyang should give warning if filename != modulename

What steps will reproduce the problem?
1. cd test/test_good
2. pyang -f cts yt5ag.yang

What is the expected output? What do you see instead?

Traceback (most recent call last):
  File "/home/mbj/src/pyang/bin/pyang", line 204, in <module>
    run()
  File "/home/mbj/src/pyang/bin/pyang", line 191, in run
    emit_obj.emit(ctx, module, fd)
  File "/home/mbj/src/pyang/pyang/translators/cts.py", line 87, in emit
    emit_cts(ctx, module, fd)
  File "/home/mbj/src/pyang/pyang/translators/cts.py", line 98, in emit_cts
    ctx.opts.cts_record_defs, debug=0)
  File "/home/mbj/src/pyang/pyang/translators/cts.py", line 314, in
from_modules
    self.handle_substmts(module, self.confdata)
  File "/home/mbj/src/pyang/pyang/translators/cts.py", line 668, in
handle_substmts
    self.handle_stmt(sub, p_elem, pset)
  File "/home/mbj/src/pyang/pyang/translators/cts.py", line 656, in handle_stmt
    self.handle_extension(stmt, p_elem)
  File "/home/mbj/src/pyang/pyang/translators/cts.py", line 526, in
handle_extension
    prefix = self.add_namespace(self.prefix_to_ns(prf), prf)
  File "/home/mbj/src/pyang/pyang/translators/cts.py", line 400, in
prefix_to_ns
    return defin.search_one("namespace").arg
AttributeError: 'NoneType' object has no attribute 'search_one'


---

> > I ran into a tricky problem: file test/test_good/yt5ag.yang contains
> > "module yt5a" so that the file basename is not the same as module name.
> > What happens is that the "revs" dictionary (instance var of Context) has
> > the *file basename* ("yt5ag" in this case) as the key. The get_module
> > method then returns None if the module name is passed as the
> > "modulename" argument. I guess this wasn't your intention, right?
> 
> The problem is FileRepository._setup() which parses the filename in
> order to figure out the module name and revision.  The right thing to
> do would be to extend _peek_revision to _peek_modulename_and_revision,
> and use it from _setup, and signal an error (warning) if the
> modulename / revision doesn't match the filename.
> 
> But in order to do this, _peek_modulename_and_revision need the
> optimization mentioned in the code -- it must not fully parse all
> modules.  So we need some kind of optimized special parser which just
> reads the module name and revision.  Probably doeable for the
> yang_parser, but I'm not sure how to do it in the yin_parser.
> 
> Alternatively, we don't do anything and treat it as the error it is.
> Somewhere we should report this error though...

Original issue reported on code.google.com by [email protected] on 10 Mar 2010 at 8:02

A leafref in a typedef is not validated

See t17 in test/test_good/yt3.yang - it is an error

Original issue reported on code.google.com by [email protected] on 10 Mar 2010 at 8:04

Extension defined in a submodule is not available in the module

Let's look at the example: in a submodule I define an extension, then I
want to use this extension in the module which includes the submodule:

% composite.yang module
module composite {
    namespace "urn:test:composite";
    prefix c;

    include submodule;    

    c:ext1 "test"; // pyang error
}

% submodule.yang
submodule submodule {
    belongs-to composite {
    prefix c; 
    }
    extension ext1 {
        argument test;
    }
    c:ext1 "test arg";
}

But when I validate the composite module by pyang I receive an error
message: "composite.yang:7: error: extension "ext1" is not defined in
module composite"

What version of the product are you using? On what operating system?
pyang 0.9.3

Original issue reported on code.google.com by [email protected] on 16 Apr 2009 at 1:26

Attachments:

• composite.yang
• submodule.yang

key leaf not recognized in choice without a container

What steps will reproduce the problem?

1. Extract the YANG module in NETCONF Monitoring Schema draft (currently at
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-netconf-monitoring-
08.txt)

2. Extract the two dependencies modules contained in
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-netmod-yang-types-0
3.txt,
ietf-yang-types and ietf-inet-types

3.run pyang -f xsd netconf-monitoring.yang

What is the expected output? What do you see instead?

Expected output is the XSD equivalent of this YANG module- seeing the
following instead:
netconf-monitoring.yang:205: error: unexpected keyword "key"
XSD translation needs a valid module

Also, if I add a container around the 'list partialLocks' block, the error
goes away.

This error also occurs when translating from YANG to YIN, but YIN is still
generated.


What version of the product are you using? On what operating system?

pyang 0.9.3 on Fedora 11 (64bit)

Please provide any additional information below.

Running yangdump on netconf-monitoring.yang module report no errors.

Original issue reported on code.google.com by [email protected] on 5 Oct 2009 at 3:27

whitespace trimming in YIN->YANG conversion

When doing the translation from YIN to YANG, it would be helpful to apply some 
whitespace trimming in 'description' arguments and similar strings, otherwise 
the result is ugly when theses strings are naturally indented in the YIN XML 
source. A typical result is:

  description
    "
                 Time To Live (or hop count in IPv6 terminology) that is
                 set in the IP headers of the (outer) tunnel packets. By
                 default, the tunnel packets inherit the value from the
                 inner (tunneled) packets.
                     ";


The trimming rule could be that all leading and trailing whitespace is removed 
and the second and following lines are justifed relative to the first line so 
that the above description would become

  description
    "Time To Live (or hop count in IPv6 terminology) that is
     set in the IP headers of the (outer) tunnel packets. By
     default, the tunnel packets inherit the value from the
     inner (tunneled) packets.";

Original issue reported on code.google.com by [email protected] on 10 Jun 2010 at 6:34

augmented module not expanded in module tree

What steps will reproduce the problem?
1. Place attached y1.yang and y2.yang in a same directory
2. run:
  $ pyang y2.yang -f tree

What is the expected output? What do you see instead?

Since y2 is augmenting y1, I like to see the expanded tree like: 

module: y2
   +-- rw    /y1:c
      +-- rw string  l1
      +-- rw uint8   l2

but I see only the contents of y2 module:

module: y2
   +-- rw    /y1:c
      +-- rw uint8   l2

What version of the product are you using? On what operating system?

svn HEAD as of today on Linux (CentOS 5.4), python 2.4.3.

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 26 Apr 2010 at 8:09

Attachments:

• yang1.yang
• yang2.yang