cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

72
Views
1
Helpful
3
Replies
khgrant
Cisco Employee

NSO Placeholder device

 

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 ??

 

Thanks & Regards,

 
Nick Khemani

 

 

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

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
khgrant
Cisco Employee

 

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.

 

 

/klacke

 

 

View solution in original post

3 REPLIES 3
khgrant
Cisco Employee

 

Hi Nick,

 

 

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));

                }

khgrant
Cisco Employee

 

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.

 

 

/klacke

 

 

khgrant
Cisco Employee

 

Thanks Michel and Klacke,

 

 

We will make appropriate changes.

 

 

Thanks & Regards,

Nick Khemani

 

Create
Recognize Your Peers
Content for Community-Ad