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

Support disambiguation of identical yang identifiers in autocli #253

Open
pheller opened this issue Aug 5, 2021 · 1 comment
Open

Support disambiguation of identical yang identifiers in autocli #253

pheller opened this issue Aug 5, 2021 · 1 comment

Comments

@pheller
Copy link
Contributor

pheller commented Aug 5, 2021

As implemented, it is possible (though likely incredibly infrequent) that two or more yang modules may be loaded that define elements with ambiguous identifiers in the absence of namespaces.

For example, suppose:

a.yang:

module a {
  yang-version "1";
  namespace "http://foo/bar/a";
  prefix "a";

  container baz {
    description "configure the baz component in the a namespace"
    ...
  } 
}

b.yang:

module b {
  yang-version "1";
  namespace "http://foo/bar/b";
  prefix "b";

  container baz {
    description "configure the baz component in the b namespace"
    ...
  } 
}

With netconf, it is no problem to supply a configuration for these identifiers:

<config>
  <baz xmlns="http://foo/bar/a">
    ...
  </baz>
  <baz xmlns="http://foo/bar/b">
    ...
  </baz>
</config>

However, with the CLI, it is not presently possible to differentiate between the identifiers.

Ideally, when such a condition exists, the CLI would allow configuring the ambiguous identifiers by using their yang-specified namespace prefixes, and command completion would enumerate them as well.

e.g.,:

clixon> set ?
  a:baz                 configure the baz component in the a namespace
  b:baz                 configure the baz component in the b namespace
clixon> set a:baz ...
clixon> show configuration
a:baz {
  ...
}
clixon>
@pheller
Copy link
Contributor Author

pheller commented Aug 9, 2021

Somewhat related, the working path shown as a result of %W in a clispec could probably omit the yang prefix unless it's ambiguous, but I can open a separate enhancement request for that if preferred.

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

No branches or pull requests

2 participants