Referencing CDB in python template

[jordanmeador]

While developing a L3VPN  template, I am trying to find a way to detect whether a VRF is already configured inside a device so that if I build another service to that VRF it does not change the vrf description. The only thing I am having issues with is how to reference the vrf list already configured in that device. From what I can see it would be something like this:

root.devices.device[device].config.vrf

and then just iterate through that list and compare to the vrf name provided by the user. Am I on the right track?

[rslaski]

More experienced guys would probably provide better answers, but I would start considering three approaches, possibly combined together:
1) Your approach, i.e. iterating through per-device VRF list inside a Python callback. It's not so NSO-ish, but it will work. If VRF names are auto-generated, it's possible to avoid collision by just assigning a different name during single transaction.
2) Using 'tags="create"' in an XML template. If a VRF name already exists, and error should be raised. The whole transaction will be failed, however.
3) To validate a VRF name service-scope, not device-scope, 'unique' statement could also be used in a YANG model.

hth

[yfherzog]

You don't actually have to iterate the list.

As the VRF name is probably the key on that list of VRFs, you can just reference it directly.

vrf_list = root.devices.device[device].config.ned_prefix_missing_here__vrf

if 'my-vrf' in vrf_list:
  do something
else:
  do something else

One thing to have in mind is that your service code is going to run also on service modifications.

Depending on the way the VRF is going to be used after you deploy the service (e.g. whether another service will add configs under the same vrf), it might be that on modification call, it's going to appear as the VRF is already in place, which might not return the result you're after.

All in all, having your code verifying nonexistence of configs that the service is about to create is a delicate point.

If you have to do it, I recommend doing it during post modification callback - there you can differentiate between service creation and service modification, and only execute the check once the service is first created (of course, if the service should allow modifying the VRF name, then again you're in a bit of a problem as your verification will not run on modifications...).

[jordanmeador]

Thanks so much!

I had completely forgotten about the ned prefix missing when I fought with this. At this point we will be using this code to check if the vrf exists and if it does we will not rewrite the description. We are replacing an old in-house provisioning tool and in some spots are just making the behavior like the old tool. 

[yfherzog]

Still, what happens when you re-deploy or modify a service instance that actually modified the description upon creation?

Will it see a description? Will it not? Will it then push a description or not? if it won't, then it might actually remove the description that it configured before? if it only reduces the refcount, will the description be deleted when some other service is removed?

The answer is mainly dependent on the way fastmap works and on corner cases regarding how this description is co-owned between different service instances of different service types, which might be not-that-trivial to predict.

It's not necessarily bad idea, but it's a delicate point.