Issue connecting to server due to mismatch of YANG module version

[sjd-xlnx]

Hello, I have a problem connecting which I have tracked down to version mismatch in an installed YANG module.

I am upgrading my environment for O-RAN, and found that when I install o-ran-file-management.yang I can no longer connect to the netopeer2 server. The error is...

ly ERROR: Augment target node "private-key-type" in grouping "asymmetric-key-pair-with-certs-grouping" was not found. (Path "/ietf-keystore:keystore/{uses='keystore-grouping'}/asymmetric-keys/asymmetric-key/{uses='ks:asymmetric-key-pair-with-certs-grouping'}/{uses='ct:asymmetric-key-pair-with-certs-grouping'}".)
cmd_connect: Connecting to the localhost:5678 as user "stevend" failed.

o-ran-file-management imports ieft-crypto-types@2019-04-29.yang

and

ietf-keystore imports ietf-crypto-types@2019-07-02.yang

By the way, I an see both versions when I do sysrepoctl -i

Module Name                   | Revision   | Flags | Owner         | Startup Perms | Submodules | Features                                   
-------------------------------------------------------------------------------------------------------------------
ietf-crypto-types             | 2019-07-02 | i     |               |               |            |                                                      
ietf-crypto-types             | 2019-04-29 | i     |               |               |            |                                                      

The ietf-keystore (which is also 2019-07-02) augments a "choice" node called "private-key-type" (which was the source of the error above) but this node only exists in the 2019-07-02 version of ietf-crypto-types, and not in the 2019-04-29 version which is used by o-ran-file-management.

Below is the extract from ietf-keystore which is augmenting the "private-key-type" from ieft-crypto-types (prefix ct below)...

  grouping asymmetric-key-pair-grouping {
    description
      "This grouping is identical to the one in ietf-crypt-types
       except that it adds a couple case statements enabling the
       key value to be encrypted by a symmetric or an asymmetric
       key known to the keystore.";
    uses ct:asymmetric-key-pair-grouping {
      augment "private-key-type" {
        description
          "Augments a new 'case' statement into the 'choice'
           statement defined by the ietf-crypto-types module.";
        container encrypted-private-key {
          description
            "A container for the encrypted asymmetric private
             key value.";
          uses encrypted-value-grouping;
        }
      }
    }

I've managed to overcome the problem by editing o-ran-file-management to use 2019-07-02 version instead, and this seems to work (at least I can connect and no errors thrown). I can live with that, but I would rather not edit these YANG modules if possible.

Is there a better way to solve this without editing the YANG modules? Is it possible to have different versions of YANG modules in use by different parts at the same time, or is this asking for trouble?

[michalvasko]

Unless you import by revision, the latest available should be imported so I think you can only modify the imports in the affected YANGs.

[sjd-xlnx]

Thanks @michalvasko. The o-ran-file-management.yang currently imports ietf-crypto-types by specific revision (when I remove that, it works). I guess another solution would be to roll-back the ietf-keystore.yang & ietf-crypto-types to the same version so there isn't a mismatch, but I don't like that idea too.

However, it is a little bit odd, as I had this working without needing to modify the YANG versions last year. So, it appears something has changed in behaviour - maybe checking of YANG modules is more thorough in latest version.

PS: I've just checked on CRs for the o-ran-file-management.yang file, and I see that in next version they are removing this requirement on specific version of ietf-crypt-types, so looks like I wasn't the only one to see this as an issue. Problem solved.

[michalvasko]

There could have been some behavior change, we try to continually improve whatever found shortcomings. If you rely on them, it will stop working sooner or later.