filter an already insert data from a comand

[mfontane]

Hi all.

I have this service

services svo-circuits create-service src-device <src-device-name>  dst-device <dst-device-name>

in the yang model :

container svo-circuits {

    tailf:info "set of SVO services for SSON/WSON circuit management";

      tailf:action create-service {

        tailf:info "service to create a new circuit";

        tailf:actionpoint svo-circuit-app-create-service;

        input {

          leaf src-device {

            description "src device";

            type leafref {

              path "/ncs:devices/ncs:device/ncs:name";

            }

          }

          leaf dst-device {

            description "src device";

            type leafref {

              //path "/ncs:devices/ncs:device[ncs:name!=current()/../src-device]/ncs:name";

              path "/ncs:devices/ncs:device/ncs:name";

            }

          }

......

}

my request is to have the possibility choose as dst-device only those name are present in the /ncs:devices/ncs:device/ncs:name exept for that is already added as src-device.

I tried to had the commented path but I ends up in a compilation error

[exec] yang/svo-circuit-app.yang:47: error: bad argument value "/ncs:devices/ncs:device[ncs:name!=current()/../src-device]/ncs:name", should be of type path-arg

which is the negative form (and wrongly I supposed could work, too) of this one, that is compilable

path "/ncs:devices/ncs:device[ncs:name=current()/../src-device]/ncs:name"; but this force the dst-device to be exactely the src-device.

suppose I have 3 device called

svoLite0   svoLite1 svoLite2

what I would like to have is someting like this

admin@ncs(config)# services svo-circuits create-service src-device svoLite0 dst-device ?       

Possible completions:

  svoLite1 svoLite2

How can solve my problem ?

[davidmb]

Have you tried use the ‘not’ XPATH function?  Not sure if it will work but ‘not’ is valid XPATH…

path "/ncs:devices/ncs:device[not(ncs:name=current()/../src-device)]/ncs:name";

[Jan Lindblad]

Both not() and != will work if you place the constraint in a must statement. The leafref path may only contain a plain path plus possibly equality tests on list key elements. I.e. the logic allowed in the path statement itself is very limited, but you can have all the logic you want in a must statement on your leaf.

[mfontane]

Thank Jan.

Yyour proposal works, but the must (for my understanding) works in a second phase, after the enter of the command.

And this could be, anyway, a good compromise to help the user to avoid wrong type.

here the yang changes

{

.....

          leaf src-device {

            description "src device";

            type leafref {

              path "/ncs:devices/ncs:device/ncs:name";

            }           

          }

          leaf dst-device {

            description "dst device";

            type leafref {

              path "/ncs:devices/ncs:device/ncs:name";

            }

            must "not(current()=current()/../src-device)"{

            error-message "Source and Destination shall be not the same device";

            }

          }

....

}

and here the CLI result:

admin@ncs(config)# services svo-circuits create-service src-device svoLite0 dst-device svoLite0

Error: 'services svo-circuits create-service dst-device' (value "svoLite0"): Source and Destination shall be not the same device

admin@ncs(config)#

admin@ncs(config)#

admin@ncs(config)# services svo-circuits create-service src-device svoLite0 dst-device svoLite1

success true

message svo-circuit-app:svo-circuits

admin@ncs(config)#

But I would like to completely remove the svoLite0  as possible chose if it is already insert as src-device.

is this possible ?

Mik

[Jan Lindblad]

The must expression validation happens in the CLI when you hit tab for completion options, if/when you run the validate command and always at commit.

The CLI will not stop you from creating an invalid configuration, and this is important. You will not be able to commit an invalid configuration, tho, and that's of course essential.

Let's say you want to make a swap so that A=1 and B=2 becomes A=2 and B=1 while it's invalid that A and B have the same value. A user entering A=2 followed by B=1 will momentarily have an invalid configuration. A non-transactional CLI would refuse that sequence. Since we're now in the transactional world, temporary inconsistencies are fine, as long as they are fixed before commit. Same thing when loading a backup. The backup will contain references to things that will be created by later lines. NSO will happily accept such dangling references as long as you don't commit.

So, no, the NSO CLI will not stop the operator from typing svoLite0. It may well be a valid thing to do, because of changes he's about to make. The CLI will not provide svoLite0 as a valid option, however, if the operator hits tab to see what makes sense.