NSO Placeholder device

[previousqna]

Hi NSO gurus

If I add a device to NSO that does not exist in the network just yet (a placeholder device):

1) I can add device to NSO via CLI

2) I can set it’s state to unlocked

3) I cannot fetch SSH host-keys (as expected since device does not exist)

If I try to instantiate a Service instance WITHOUT even using this planned device, NSO complains and will not let me instantiate any services unless I’ve removed this planned device. I’ve tried to change this device’s behavior in NSO and tried various commit options but to no avail.

Surely, we can create a planned device in NSO (obviously without initial sync-from), without NSO complaining about Service instantiation that does not even involve this offending device ??

Is this a bug or a feature ? Thoughts/comments ??

[previousqna]

When creating a service package, the code below is inserted by default to the *RFS.java.

You can either remove it or comment it out and this error will not show up.

            for (NavuContainer device : managedDevices) {

                if (device.list("capability").isEmpty()) {

                    String mess = "Device %1$s has no known capabilities, " +

                                   "has sync-from been performed?";

                    String key = device.getKey().elementAt(0).toString();

                    throw new DpCallbackException(String.format(mess, >>key));

                }

[previousqna · Accepted solution]

That is one thing - the code snippet below is more there for convenience in the example collection, remove it.

However, more complicated is the fact that we cannot apply any templates unless the capabilities for the device are there.

This is operational data that gets added after connect.

A template typically has the structure:

<config xmlns="http://tail-f.com/ns/config/1.0">

   <devices tags="nocreate" xmlns="http://tail-f.com/ns/ncs">

   <device>

     <name>{$DEVICE_NAME}</name>

     <config tags="merge">

       <ip xmlns="urn:ios">

       .....

     </config>

   </device>

   <device>

     <name>{$DEVICE_NAME}</name>

     <config tags="merge">

        <xxxxx xmlns="urn:somethingelse">

        .....

The idea being that the same template can be used regardless of device type. The xmlns statements match or don't match If they match, whatever resides below will be applied, if no match, whatever resides below will be skipped.

In the case of non-existing devices, the capability data must be manually entered as part of the onboarding process if we want to apply templates to non-existing devices.

Device can be set to southbound-locked, making the commit go into CDB only, i.e no networking at all.

Later when device comes alive, we can do sync-to. This is usually quite complicated. sync-to will overwrite the entire config of the device. Scary.