If there are 3 NSO nodes - master, slave 1 and slave 2, how do we set up the device encrypted passwords? I know the AES encryption key is to be kept the same on all three nodes. But does the password have to be set with HA enabled or it is ok to set them separately (HA disabled) on all 3 nodes and then enable HA? Will that work? What do you mean by "device encrypted passwords"? Are they config data stored in NSO's CDB? In that case, you should set them in the master node, and they will be replicated to the slave nodes. The keys are the same in all nodes, but still, when encrypting a string, the initial vector will be randomly generated. So, you cannot assume that for a given plaintext string, the encrypted value calculated by different nodes (or even the same node at different times) will be the same. /Ram ... View more

The NSO env runs  in VM, which has 4 CPU cores and 8G memory. NED is huawei cli-ned. So, is it normal? Are you asking if it is normal for NSO to take 8 minutes to calculate southbound diff for a device? It depends on the amount of config in CDB, that NSO has to go through, to get the diff. Given that I have seen southbound diff times that are MUCH larger than 8 minutes, I would say it looks quite normal. ps: Can i config the nso's cpus and memory usage by ncs.conf? No, it is not possible to control such resource usage from ncs.conf. /Ram ... View more

@ajbharad wrote: get_object via Maapi API is working as expected where as via CDB API it`s not. Can anybody tell me what wrong am I doing here ? >>> val = maapi.get_object(sock_maapi, th, 500, "/org-openroadm-alarm:active-alarm-list/activeAlarms{SM/HW_ENVMON_PEM_ALARM/22#CHASSIS/LCC/1}") >>> val = cdb.get_object(cdb_socket, 1, "/org-openroadm-alarm:active-alarm-list/activeAlarms{SM/HW_ENVMON_PEM_ALARM/22#CHASSIS/LCC/1}") get_object returns *all* the children for a given list instance. But only *N* children are filled with the correct values. The rest of them are dummy values, with 'UNKNOWN_TYPE' and 'badval'. In your maapi call above, you ask for 500 values under that list instance. In the CDB call, you ask only for 1 value, so you get a proper value only for the first leaf in the list, which it the key. Increase that param in the CDB call, and you can get the same output as your maapi call above. /Ram ... View more

@suvdeshm wrote: Can we make RESTCONF calls in the call for ncs--reload? Hi, I don't get the question. Do you want to perform "ncs --reload" via RESTCONF? I'm afraid that is not possible. If not, could you clarify your question? /Ram ... View more

If you want those three leaves to be the keys, there is no way to keep the structure the same. As for validation, maybe you can combine the 'when' expressions and the enum values for 'ifType' into a single must expression, something like:   must "(...ned-id='cisco-iosxr' and ifType != 'fastethernet') or (...ned-id='cisco-ios' and ifType != Eth-Trunk) ..." etc.   Replicating the leafref will be difficult. Maybe you can use a completion point to supply the valid completions yourself, by reading the configured interfaces and the interface type from CDB? But of course, that does not prevent someone from providing a different value than what is offered as completions - ie., it does not fully mimic the behavior of a leafref. Still, might be an option. Otherwise, I can't see an easy way to change the model as you want, and still preserve the same semantics/validation. /Ram ... View more

When one presses tab in this command, content of ncs-run directory gets listed. I would like to have similar behavior for my service such that when I do: my_service service_name <tab> everything in home directory should get listed. What you need is a completion callback. You can use the extension tailf:cli-completion-actionpoint  in your model, and implement a callback to provide the completions. A small snippet is provided in the javadoc for com.tailf.dp.Completion in the NSO documentation. I provide it here for reference: Having a YANG model snippet like the following: container application { leaf file-name { type string; tailf:cli-completion-actionpoint "file-complete" { tailf:cli-completion-id "path"; } } } The corresponding completion action is as follows: @ActionCallback(callPoint = "file-complete", callType = ActionCBType.COMPLETION) public Completion completion(DpActionTrans actx, char cliStyle, String token, char completionChar, ConfObject[] kp, String cmdPath, String cmdParamId, ConfQname simpleType, String extra) throws DpCallbackException { .... // User processing of the completion .... CompletionReply reply = Completion.newReply(); reply.addCompletion("completion-entry1", null); ... reply.addCompletion("completion-entryN", null); reply.setCompletionInfo("my-info"); reply.setCompletionDesc("my-description"); return reply; } /Ram  ... View more