cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
916
Views
10
Helpful
5
Replies

What are the advantages of using a device template over building a small service package?

rhinst001
Level 4
Level 4

I'm trying to understand why I would want to use device templates to commission my devices, rather than, for example, building a series of small service packages for the constituent services (snmp, tacacs, ospf, etc.) and then stacking those services into a higher-level service package (agg-switch, pe-router, ce-switch, etc).

Isn't the service model-based approach kind of the whole point of NSO? Is there something I'm missing?

Thanks.

1 Accepted Solution

Accepted Solutions

I've myself pondered on the benefits of device-templates over building a service-package itself. Given all the extra benefits we get with services in NSO (precision, traceability, service check-sync auditing, re-deploy etc).

Even when doing "golden" config like things, there are merits of using service-packages. As configs can be updated and things "removed" by simple re-deploy.

One area where device-template may be useful is when running compliance-reports in NSO. Especially for brownfield scenarios where it might not be feasible (or very expensive) to build services and perform service-reconciliation.

View solution in original post

5 Replies 5

sspehar
Level 1
Level 1

Hi Rob!

You can use device templates for direct manipulation of device configuration, either through CLI or REST, but you're right, the point of NSO is to model your services and use that for provisioning them on the network. In this case, if you're using mapping with templates, you will, based on device-templates, create config-templates which are then part of your service (stored in the templates folder) and are used for mapping service input data into the device configuration.

(See Development document, Ch. 11 & User Guide Ch.3 Device templates)

Use a service template for anything that has a lifecycle (create, modify, move, delete)

Device templates are for basic configuration where there is no lifecycle.

Cheers,

KJ.

But what part of the config doesn't have a lifecycle, in reality?  Some things, like authentication settings, tend to remain relatively static for long periods of time, but that just means the lifecycle is longer and slower-changing.  Is there truly any part of your device configs about which you feel safe saying "this will never evolve" ?

It seems like maybe device templates are intended as a "light" version of service models, where the device-template is the equivalent of your xml config-template and instead of building a yang model, you define a flat list of typeless "leafs" just by using variables in the device-template. 

But it seems to me that if you're going to go that far, why not take the few extra steps to build a service model and gain the associated benefits?


So, going back to my original question, is there any added benefit to using device-templates over service models, other than "it's a little faster/simpler" ?

And by the way, thanks for taking the time to reply!

I think it's important to note, that once you use a service to configure something then you couple those device configurations with the service.

That is to say, that those configurations on the device should only be managed by the service.

If you change those configurations outside of the service instance that created them, then you are getting the service out of sync, which means that if you will, later on, redeploy the service instance that created them, then you will revert the configurations on the device to an older state, which might not be valid.

So, if you have basic configurations which no one will touch outside of the service that created them, then you can implement those as part of a service, but if for example, you expect someone to change the TACACS configs on the device outside of the service, then better not use a service to manage it, as once you redeploy the service instance, you might get your device inaccessible.

I've myself pondered on the benefits of device-templates over building a service-package itself. Given all the extra benefits we get with services in NSO (precision, traceability, service check-sync auditing, re-deploy etc).

Even when doing "golden" config like things, there are merits of using service-packages. As configs can be updated and things "removed" by simple re-deploy.

One area where device-template may be useful is when running compliance-reports in NSO. Especially for brownfield scenarios where it might not be feasible (or very expensive) to build services and perform service-reconciliation.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the NSO Developer community: