Fails on imported module with tailf:symlink extension leaf

[liggetm]

Fails to generate classes whenever an imported module is used via symlink extensions:

... import SNMPv2-MIB { prefix mib2; } ... tailf:symlink contact { tailf:path "/mib2:SNMPv2-MIB/mib2:system/mib2:sysContact"; } ... extension symlink { argument name { tailf:arg-type { type tailf:identifier; } } ... 'ant jar' results in: ... generate: [mkdir] Created dir: /home/mark/YangGen/src/gen [exec] yang/test.yang:27: warning: imported module SNMPv2-MIB not used [exec] WARNING: unused_import, aborting.e.msg [exec] atlas-system contains errors ... I've opened an issue with pyang concerning the 'imported module not used' error message.

[Emil-Tail-f]

What happens if you provide the --jnc-ignore-errors option to pyang in the build script? This is a work-around for using proprietary extensions with the open source version of pyang.

[liggetm]

Thanks for coming back to me. If I use --jnc-ignore-errors I successful get a generated jar, but there are no fields or accessors for the symlink'd values.

[liggetm]

Guys - any response on this? Just it's now blocking some work for us. Thanks

[klacke]

On 05/14/2013 11:38 AM, liggetm wrote:

Guys - any response on this? Just it's now blocking some work for us. Thanks

This is highly non-trivial to do well, Are you doing symlink to leaves only, or do you also symlink to containers and lists.

/klacke

[liggetm]

Thanks klacke, I appreciate it's non-trivial. Right now I'm being given symlinks to leaves only.

[klacke]

On 05/14/2013 03:47 PM, liggetm wrote:

Thanks klacke, I appreciate it's non-trivial. Right now I'm being given symlinks to leaves only.

---

Reply to this email directly or view it on GitHub: https://github.com/tail-f-systems/JNC/issues/18#issuecomment-17876843

Ok,

We had a discussion internally about this, the same problem, i.e the fact that the construct

container foo { tailf:symlink x { tailf:path "/foo/bar"; } }

cannot be dealt with by NETCONF managers that are - well - unaware of tailf:symlink

Had the construct been defined as

container foo { leaf x { type MyType; tailf:symlink "/foo/bar"; } }

instead, then all would have worked seamlessly

It's technically complicated to do a proper solution with the current tailf:symlink construct, the main reason being that a symlink may point to containers and lists, not only leaves.

My suggestion to you, to get going now, is to rewrite these models, so that when exposing the yang models to the JNC compiler, you have regular leaf elements instead,

This can be automated with a pyang plugin, that does source code transformation, replacing the construct

tailf:symlink x { tailf:path "/foo/bar"; }

with

leaf x { type string; }

Such a pyang plugin could then be integrated into your Makefiles prior to invoking the JNC compiler.

I realize this is not the perfect solution, but it can at least be done now, today.

/klacke

[alrighttheresham]

Hi Klacke, the reason we are using tailf:symlink is because to support the functionality we want someone in tailf told us this was the way to do it. We have implemented the functionality on the NE because of a tailf recommendation.

I will speak with the team internally and get them to raise on the next tailf call, if you dont mind I'll copy you on the email to discuss alternatives.

[klacke]

On 05/15/2013 12:04 PM, alrighttheresham wrote:

Hi Klacke, the reason we are using tailf:symlink is because to support the functionality we want someone in tailf told us this was the way to do it. We have implemented the functionality on the NE because of a tailf recommendation.

Yes, I heard that, and symlinks is sometimes a good solution to the problem, for example pointing into a hidden /confdConfig tree.

/klacke

[klacke]

On 05/15/2013 12:04 PM, alrighttheresham wrote:

Hi Klacke, the reason we are using tailf:symlink is because to support the functionality we want someone in tailf told us this was the way to do it. We have implemented the functionality on the NE because of a tailf recommendation.

I will speak with the team internally and get them to raise on the next tailf call, if you dont mind I'll copy you on the email to discuss alternatives.

We have added a variant of symlink, now called tailf:link, it's used as:

leaf x { type string; tailf:link "/ffo/bar"; }

this is the same as

tailf:symlink x { path "/ffo/bar"; }

The JNC compiler will work perfectly with this, this has been backported to the ConfD 4.2 branch, so it'll be available in some ConfD 4.2 release soon. The JNC compiler will just treat is yet another leaf, which is exactly what you want the manager to do.

This will solve your problems I think, and it's also the right thing (TM) and it'll be good for ConfD/NCS users as well

Thanks

/klacke

[alrighttheresham]

Hi Klacke, can you provide a release date for when this will be GA in ConfD 4.2?

Thanks, Damian.

[klacke]

On 5/30/13 4:10 PM, alrighttheresham wrote:

Hi Klacke, can you provide a release date for when this will be GA in ConfD 4.2?

Thanks, Damian.

I took a peek at the release schedule, ConfD 4.3 is slated for June 14 and 4.2.1 slated for July 5.

I think maybe this issue is better on the Tailf RT system, the guys there are way better on this than me!

/klacke

[alrighttheresham]

Thanks Klacke appreciate the response.

Damian.

On 30 May 2013, at 21:12, Claes Wikstrom notifications@github.com wrote:

On 5/30/13 4:10 PM, alrighttheresham wrote:

Hi Klacke, can you provide a release date for when this will be GA in ConfD 4.2?

Thanks, Damian.

I took a peek at the release schedule, ConfD 4.3 is slated for June 14 and 4.2.1 slated for July 5.

I think maybe this issue is better on the Tailf RT system, the guys there are way better on this than me!

/klacke — Reply to this email directly or view it on GitHub.