I believe this is done because on some devices the xconnect is created with "mpls control-word" set. So (unless you have also set it in NSO) NSO has to clear it with the no command when it creates the xconnect.   It shouldn't cause a problem, but if it does then you should raise a TAC case. ... View more

No it's not possible unfortunately.   Also, you're not using the deref() function correctly. You should pass in a leaf of type leafref, but you're using it on string leaf. Deref will get the value of the leaf pointed at by the leafref.   In standard Xpath you might be able to do what you want using the local-name() function. But this isn't available in a leafref path. As you can see in the error, the path should be of type path-arg (which is only a subset of the Xpath syntax - check out the YANG RFC for more details).   I think the only way to achieve what you are after is using a choice node with a seperate leaf (of type leafref) for each service (and you will need add each module to the YANGPATH in the Makefile as you said). ... View more

There are some options in ncs.conf you can try out. They are documented in the ncs.conf man pages. After you update ncs.conf you need to restart NSO.   /ncs-config/cli/commit-message (boolean) [true] CLI prints out a message when a commit is executed   /ncs-config/cli/suppress-commit-message-context (string) This parameter may be given multiple times. A list of contexts for which no commit message shall be displayed. A good value is [ system ] which will make all system generated commits to go unnoticed in the CLI. A context is either the name of an agent i.e cli, webui, netconf, snmp or any free form text string if the transaction is initated from Maapi     ... View more

Hi,   These options have been hidden, not removed. They are in the debug hide-group. To unhide them you need to add the hide-group to your ncs.conf. Add the following lines:   <hide-group> <name>debug</name> </hide-group> After restarting NSO, you will be able unhide this group in the CLI using the unhide command:   ncs_cli -u admin admin connected from 127.0.0.1 using console on MMADDERN-M-D0DF admin@ncs> unhide debug [ok][2019-07-05 11:53:05] admin@ncs> request java-vm ? Description: Control of the NCS Java VM Possible completions: restart - Restart the Java VM start - Stop the Java VM stop - Stop the Java VM ... View more

No it is not possible. You either need to do the loop in your python code and apply the template on each interation (this can be slow), or you need to create a YANG structure in the CDB that you can loop over in the template.   There's some good information about this in the Development Guide. Look at "Passing deep structures from an API" in the Templates section.   If your template is really simple (like just setting one leaf), you could do this in the python code instead and not use the template. ... View more

Hi,   Using the JSON-RPC login is recommended and is not a hack (it's mentioned in the REST API user guide - at the bottom of the Introduction section).   I think the problem you are seeing is that REST doesn't allow granular transaction or session control. For each request, a new transaction is created automatically and once completed, the session ends. You need to authenticate each request so that a new session can be created. The REST / RESTCONF server uses an authentication cache, so it will be fast.   Alternatively, you can use the JSON-RPC API, where you have more control over the session and transactions, but it can require many individual API calls to do the same thing that can be done in one REST / RESTCONF call.   ... View more

I think this is more a generic python question rather than NSO. As far as I know, there is nothing stopping you running your handler in a seperate thread. Check out the python threading library.   If you're anticipating there will be many of these long running threads executing in parallel, it's a good idea to minimise the number of transactions you keep open. For example, if your IOS upgrade takes 10 minutes, don't start a write transaction at the start, if you only need to write the result at the end. Also remember actions (like ios exec) don't need an open transaction. Check out "Example 81: Action request without transaction" in the Python API section of the Development Guide.   ... View more

Yes almost. I should have given a more complete example sorry - here is the YANG:   container ios-upgrade { leaf target-version { tailf:info "IOS version string. Leave empty to skip upgrade"; type string; } leaf image-file-path { tailf:info "The full path prefix including trailing / to the directory of the image to copy"; type string; } leaf image-file-name { tailf:info "The image filename (will be appended to the file-path prefix"; type string; } list request { tailf:info "Device to upgrade to target version"; key device; leaf device { type leafref { path "/ncs:devices/ncs:device/ncs:name"; } } leaf result { config false; tailf:cdb-oper { tailf:persistent true; } type enumeration { enum skipped; enum error; enum reloaded; } } } }   A subscriber registers a node in the CDB and watches for changes below that node. So in the example '/ios-upgrade/request/device' is simply a leaf in a list. When the leaf is created/modified, the subscriber is triggered. So adding a entry to the request list will cause the upgrade process to start for the device given. This entry could be written by an action, or service or directly through the CLI, WebUI etc.   This is the same way the resource-manager package works (if you're familiar with that).   In my example, I'm using the same image for every request, but you could set the image per request (which is how you have it your YANG).   Regarding the transaction lock, inside service create code, the transaction is already running and has a global lock, which is why you should keep this code efficient. Code in other callbacks for actions and subscribers doesn't have this lock and you create your own Maapi transactions.   You could do the upgrade directly in an action rather than a subscriber, the code would run the same way, but the interface you use to trigger the action (i.e. CLI, REST etc) would probably time out waiting for it run (although the timeouts can be configured in ncs.conf). By introducing the subscriber you are doing the upgrade asynchronously. It also means you can trigger the upgrade safely from service code (if it makes sense to) using the reactive fastmap design pattern.   ... View more