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

prefix handling is incomplete #5

Open
pborman opened this issue Oct 1, 2015 · 7 comments
Open

prefix handling is incomplete #5

pborman opened this issue Oct 1, 2015 · 7 comments

Comments

@pborman
Copy link
Contributor

pborman commented Oct 1, 2015

goyang tends to ignore prefixes. In openconfig we do not expect to see conflicts on names sans prefixes, but for general use, goyang must support prefixes better.

@andaru
Copy link
Contributor

andaru commented Nov 11, 2015

In our present usages, one area we've run into a concern with not having prefixes is for type names - since types are often pulled in from other modules (e.g., common prefix inet), so we describe the type name as inet:as-number in one place, and as-number in another, because we receive only as-number back from goyang.

It thus seems preferable for users who do care about prefixes to get back the fully qualified type name (i.e., that with the source module prefix) from things like (*yang.Entry).Type.Name.

@r-cc-c
Copy link

r-cc-c commented Jul 21, 2017

Just FYI. I got this error when parsing openconfig-bgp: "../policy/openconfig-policy-types.yang:123:7: unknown prefix: yang for type hex-string". pyang didn't complain about this.

@pborman
Copy link
Contributor Author

pborman commented Jul 21, 2017

I believe pull request 60 may resolve this.

@r-cc-c
Copy link

r-cc-c commented Jul 24, 2017

Thanks pborman. FYI, I just tried the latest (with #60 and #61). Same error appear.

@pborman
Copy link
Contributor Author

pborman commented Jul 24, 2017

Can you provide instructions on how to reproduce this, including where all the .yang files have come from and what version? It would be great if you could just say

mkdir foo
cd foo
git clone ....
git clone ....
git cone https://github.com/openconfig/goyang
cd goyang
go build
./goyang ...

So I can reproduce exactly what you are seeing.

@r-cc-c
Copy link

r-cc-c commented Jul 24, 2017

Thanks Again! I discovered on my script the policy-types.yang file appear twice. It was my bad.
Thanks for your help!

@rski
Copy link
Contributor

rski commented Dec 21, 2017

Looks like leafs (and maybe leaft-lists and uses leaf-lists) don't have prefixes set, because ToEntry() doesn't set a prefix in these cases.

Here is a snipper that shows that:

git clone https://github.com/openconfig/public /tmp/public

package main

import (
	"fmt"
	"os"
	"path/filepath"
	"strings"

	"github.com/openconfig/goyang/pkg/yang"
)

func main() {
	yangDir := "/tmp/public/release/models"

	ms := yang.NewModules()
	filepath.Walk(yangDir, func(path string, info os.FileInfo, err error) error {
		if !strings.HasSuffix(path, ".yang") {
			return nil
		}
		return ms.Read(path)
	})

	for _, k := range ms.Modules["openconfig-isis"].Grouping {
		if k.Name == "isis-overload-bit-reset-config" {
			e := yang.ToEntry(k)
			fmt.Printf("Prefixes:\n%s:%s\n%#v\n", e.Prefix.Name, e.Name, e.Dir["delay"].Prefix)
		}
	}
}

Results in:

go run *.go
Prefixes:
oc-isis:isis-overload-bit-reset-config
(*yang.Value)(nil)

Maybe adding a

if e.Prefix == nil {
		if m := RootNode(e.Node); m != nil {
			e.Prefix = m.getPrefix()
		}
	}

in these three cases is the right thing to do?

edit by wenovus: #70 resolves this issue.

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

4 participants