ā01-31-2020 01:45 PM
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?
ā01-31-2020 03:51 PM
ā02-02-2020 12:37 AM
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...).
ā02-03-2020 09:40 AM
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.
ā02-03-2020 11:10 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide