So this usually means that the packages on the slave and master NSO nodes do not match _exactly_.  The CDB schema for both NSO nodes needs to be identical. Since the packages define the CBD schema, NSO version and the loaded/running packages need to be exactly the same on both master/slave NSO nodes before enabling HA, which replicates the Master CBD contents to the Slave. ... View more

So, the purpose of the Create callback - and Fastmap - is to write only the create function for the service instance and allow Fastmap to infer the update and delete functionality from that.  Placing create/update/delete specific code within the create_cb() is not advised as it may effect Fastmap operation. The pre/post mod functions are 'outside' of the Fastmap operations, thus the potential need to differentiate create/update/delete functions. Curious what you are attempting where you need to differentiate in create code.   ... View more

I'm curious why you are putting all this device-type specific code in to the Service model YANG.   Generally, a basic concept of NSO is to make the Service model abstracted from the device type and have the mapping code take care of the device-type specifics - preferably in the template.   In this way the Northbound interaction with the Service model can remain the same even if the underlying device(s) change from one vendor to another - which is handled in the template by just adding a stanza in the template for the new device-specific configuration. ... View more

Right, this is always an ask... but always hard to answer for any specific situation. Given that every deployment is going to be different... #devices, # services, complexity of services, amount of config per device, etc... it is hard to even attempt a ball-park number... What I have seen is customers test and monitor the resources of their specific solution (much like is discussed in this thread), starting with a VM with sizable memory and vcpu allocations - so as not to run out of a resource, which usually presents as some strange behavior and not a nice message like 'out of memory'.  Then the VM can be tuned 'down' to what you think is required with of course growth consideration. In addition to memory and CPU processing (clock rate, # vcpu's, etc), in VM deployments you also need to consider storage media access performance, as NSO will journal CDB info to disk.     ... View more

Likewise, I am a bit confused on what you are attempting to do. Generally, templates are generated from the CDB config schema (device config, service instance config, etc.) that you want to parameterize and applied via the template.apply mechanism.  Applying the template sets the CDB config specified in the template in you transaction.  Applying the transaction, then commits those changes. Although it seems feasible via some python code, I've not seen a case where the config template is generated 'on-the-fly' and then applied in an action execution, and certainly haven't seen any maapi methods for that specifically. In your code below - 'i.name' will be the name the template ('i.name'.xml filename) expected to be found in your packages/<service>/template directory: template.apply(i.name, vars) Here's an example of applying a template in a transaction:     @Action.action     def cb_action(self, uinfo, name, kp, input, output):         self.log.info('action name: ', name)           # open read/write transaction         with ncs.maapi.single_write_trans('admin', 'UP') as t:               vars = ncs.template.Variables()               vars.add('DEVICE', input.device)               vars.add('HNAME', input.hname)               vars.add('DNAME', input.dname)                 # when calling a template it needs a context node, normally, for a service               # this is the service node. Here we want context to point to devices tree...               root = ncs.maagic.get_root(t)               context_node = root.ncs__devices               # create a Template object, passing in the context node               tmpl = ncs.template.Template(context_node)               # apply the template.               tmpl.apply('tempBar-template', vars)                 # commit transaction including template config changes               t.apply()    $ cat tempBar-template.xml <config-template xmlns="http://tail-f.com/ns/config/1.0">   <devices xmlns="http://tail-f.com/ns/ncs">     <device>       <name>{$DEVICE}</name>       <config>           <!--  juniper stuff -->           <configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm">               <system>                   <host-name>{$HNAME}</host-name>                   <domain-name>{$DNAME}</domain-name>               </system>           </configuration>           <!--  juniper stuff -->       </config>     </device>   </devices> </config-template> ... View more

Can you provide the NSO Version?? Thx. ... View more

You are in essentially creating a lock deadlock when you attempt to execute an action within the create_cb: You start execution of a create callback... this starts a transaction which acquires the global lock...     While executing within this global lock...         You call issue a call to an action... which, you guessed it, starts another transaction               This new transaction will attempt to acquire the global lock - and since it is already in-use by your create callback... it will wait for it to become available.                But, the create callback will never complete because this action is waiting... forever for the lock. Calling a function or action (if it could be) that takes a large time (in excess of milliseconds) is highly frowned upon in NSO create code and would obviously be devastating to NSO transaction throughput performance.  The create_cb() call should be streamline and get out of the critical section (global lock) as quickly as possible. To handle time expensive operations such as sync-from (which by the way is generally not good practice to do on each create call - again for performance and risk issues (what are you getting on sync-from?)) the action must be called from an action or handled via reactive-fastmap staging.     ... View more

Hello, I just tried the exact commands that you performed and was successful.. (details below) That suggests that maybe there are differences in your environment, perhaps a firewall?   If you enable the NSO southbound trace to the device, you may gather some more information on why the sync-from is failing...   admin@ncs> configure Entering configuration mode private [edit] admin@ncs% set devices device ios0 trace raw [edit] admin@ncs% commit admin@ncs% request devices device ios0 disconnect admin@ncs% request devices device ios0 connect result true   Trace file will be creates at ~ncs-run/logs/ned-cisco-ios-cli-3.0-ios0.trace   Tail this file during a sync-from and see if there is any interesting failure information:   ~/ncs-run/logs$ tail -f ned-cisco-ios-cli-3.0-ios0.trace >> 15-Jul-2019::14:14:25.273 user: admin/37 thandle 174 hostname NSO-VM-1 device ios0 CLI CONNECT to ios0-127.0.0.1:10022 as admin (Trace=true) -- SSH connecting to host: 127.0.0.1:10022 -- -- SSH initializing session -- *** input 15-Jul-2019::14:14:25.335 user: admin/37 thandle 174 hostname NSO-VM-1 device ios0 *** admin connected from 127.0.0.1 using ssh on  ios0>   <.....>     ======= SUCCESSFUL Sync-from ============   ~ncs-run$ ncs --version 5.1.0.1 ~ncs-run$ echo $NCS_DIR /Users/lmanor/NCS/releases/nso-5.1.0.1 ~ncs-run$ ncs-netsim create-network $NCS_DIR/packages/neds/cisco-ios-cli-3.0 2 ios DEVICE ios0 CREATED DEVICE ios1 CREATED ~ncs-run$ ncs-netsim start DEVICE ios0 OK STARTED DEVICE ios1 OK STARTED ~ncs-run$ ncs-setup --netsim-dir ./netsim --dest . --package $NCS_DIR/packages/neds/cisco-ios-cli-3.0 Using netsim dir ./netsim ~ncs-run$ ~ncs-run$ ncs ~ncs-run$ ncs_cli -u admin admin connected from 127.0.0.1 using console on NSO-VM-1 admin@ncs> show packages packages package cisco-ios-cli-3.0 package-version 3.0.0.4 description "NED package for Cisco IOS" ncs-min-version [ 3.0.2 ] directory ./state/packages-in-use/1/cisco-ios-cli-3.0 component upgrade-ned-id upgrade java-class-name com.tailf.packages.ned.ios.UpgradeNedId component cisco-ios ned cli ned-id cisco-ios-cli-3.0 ned cli java-class-name com.tailf.packages.ned.ios.IOSNedCli ned device vendor Cisco NAME VALUE --------------------- show-tag interface build-info date "2019-04-13 20:38:10" build-info file cisco-ios-cli-3.0-source-3.0.0.4.tar.gz build-info arch .darwin.x86_64 build-info java "compiled Java class data, version 50.0 (Java 1.6)" build-info package name cisco-ios-cli-3.0 build-info package version 3.0.0.4 build-info package ref 3.0.0.4 build-info package sha1 This_Is_An_Example_NED build-info ncs version 5.1.0.1_HEAD build-info ncs sha1 This_NED_should_not_be_used oper-status up [ok][2019-07-15 13:58:43] admin@ncs> request devices connect connect-result { device ios0 result true info (admin) Connected to ios0 - 127.0.0.1:10022 } connect-result { device ios1 result true info (admin) Connected to ios1 - 127.0.0.1:10023 } [ok][2019-07-15 13:59:02] admin@ncs> request devices sync-from sync-result { device ios0 result true } sync-result { device ios1 result true } ... View more

We're going to need a little more to try help you out here...   NSO version? What is the ncs-netsim lab that you mentioned? From NSO examples.ncs? from dcloud? What does the devices.xml file contain? What have you done to get to where you are now? ... View more

What do you mean by ‘repeating’? Please provide some more info on what your problem is… perhaps an example would help… Is this in CLI, action python/java code? ... View more

That appears to be a quite different problem than how to config HA.   Seem's you'd have an access problem from any RESTCONF command toward NSO...   A few questions: Did you restart NSO after setting changes in ncs.conf? Are you attempting RESTCONF commands from the same server that NSO is running on? If not, try the curl commands locally... any different results? If from remote, does the NSO server have a firewall enabled, that may be rejecting the call? Try using telnet to determine if the port is accessible from the remote node - s hould connect to NSO $ telnet 192.168.56.101 8080 Trying 192.168.56.101... Connected to 192.168.56.101. Escape character is '^]'.   ^] telnet> quit Connection closed.   ... View more