12-14-2017 07:14 AM - edited 03-01-2019 04:03 AM
Have a service model in Python, when deleting, need the transactions to be done as a no-networking. Is it possible to use the pre_modification to modify the transactions flags and set the no-networking if it is not already set.
Solved! Go to Solution.
12-15-2017 01:22 AM
I don't think this is a good idea. To change the transaction semantics behind the user's back is bound to become problematic. Remember that a transaction may contain many other changes than this single service. The service instance deletion may be caused by the operator loading a rollback or backup from last week with thousands of changes. If all of that would be set to no-networking because of a single service, I'm sure operators would be more surprised than happy.
Maybe there's another way to accomplish your goal. Could you explain why you would want a service deletion to be no-networking?
/jan
12-15-2017 01:22 AM
I don't think this is a good idea. To change the transaction semantics behind the user's back is bound to become problematic. Remember that a transaction may contain many other changes than this single service. The service instance deletion may be caused by the operator loading a rollback or backup from last week with thousands of changes. If all of that would be set to no-networking because of a single service, I'm sure operators would be more surprised than happy.
Maybe there's another way to accomplish your goal. Could you explain why you would want a service deletion to be no-networking?
/jan
12-15-2017 01:47 AM
We are using a service model which uses the vbranch function pack. When our service model is removed, it causes the vbranch config to be removed, which causes the virtual network function to be ceased. Our service model also pushed config into the VNF, but as the VNF has been ceased, you get a NED error, as the VNF does not exist anymore.
12-15-2017 03:35 AM
Yes, this is a well known service design issue. What you have to do is to change your design to decouple the creation (and thus destruction) of the device from your service instance by an intermediate subscriber.
Currently your service is writing configuration to a lower level service which results in the creation of the virtual device. Instead,
- make a new package with a YANG model allowing a client to write requests for virtual devices to be spun up
- write a subscriber in this package that ensures the virtual device is created/destroyed in the proper way
- update your current service code to use this new package instead of the service you're currently using to spin up
With this design, the device will remain alive when you commit the service instance removal. The subscriber will remove the device shortly after.
Makes sense?
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