Is there any where to do two separate device config commit in one NSO service commit?

[haoywang]

Hi Experts

I've met a issue recently and wonder if anyone have met similar situation.

I need to commit two separate config commit in one service, like:

commit config A to device

wait for 10s 

commit config B to device

If I make A and B two separate services, I need to manually manage the rollback such as I need to rollback config A when there is any issue when commit config B.

Is there a way to do two separate device config commit in one NSO service commit so it can rollback automatically when fail.

Thanks

[Jan Lindblad]

The design pattern you are looking for is called Reactive FastMap, or RFM for short. There are plenty of material about it here on the Hub, in the documentation and among the examples. Ask again if you don't find it.

WIth RFM you would make a single service that does both things in the create() method. But it would only do the first part if a certain condition in the environment isn't met (e.g. a VM already exists, IP is allocated, peer is responding, message is received from somewhere, ...) When that triggering event happens, some mechanism redeploys your service, and the service code will do both the first part A and part B.

I hope very much for your sake that you will find a better triggering mechanism than "wait 10s", that sounds very unreliable and wasteful. Timeouts are bad; they are usually both too long and too short at the same time.

[haoywang]

Hi Jan

Thanks for your response.

Actually the first step of my service is to config a route on device A and advertise it to device B.

Wait for 10s is to wait the device B to receive the route.

The second step is to config a different route on device A and advertise it to device C.

I will look for the related info.

Thanks

[Jan Lindblad]

Good. Then I suggest that instead of "wait 10s", you implement something that checks every 2s if the route is advertised, and if it is, triggers the re-deploy of the service. I'm quite sure you don't want to build slow systems (that often wait 8s for no reason) and fragile systems that fail every now and then (because it took 12s, or 300s).

[haoywang]

One more question

As I understand, the procedure should like this:

1. deploy route X on device A

2. wait for device A to receive route X

3. redeploy the service which deploy route X and route Y

My question is, if something wrong happened during step.3, the redeploy can rollback automatically, but will the step.1 being rolled back also?

[Jan Lindblad]

---

 As I understand, the procedure should like this:

1. deploy route X on device A

2. wait for device A to receive route X

3. redeploy the service which deploy route X and route Y 

Yes, something like that.

My question is, if something wrong happened during step.3, the redeploy can rollback automatically, but will the step.1 being rolled back also?

---

It would be easy to program that the service instance removes itself on failure, but do you really want that?

If you execute some command that runs synchronously, your expectation is that at the end of the command, you'll see some sort of indication that the command is complete, and that the outcome is success or failure.

If you have an async operation, like the one here, do you think it should just delete itself if it fails? That would break transactionality rules, and confuse many users. The user configured a service, and a few seconds later it's just gone?

It would of course be nice if the failed service sent an alarm or something like that to alert the user that it failed. Maybe the user can correct the problem and re-deploy the service again. Maybe it works this time. Or delete it.

[haoywang]

In our async operation, the service will be in processing status after user deploy it. When the service deploy is finished, if it succeed, the service is create otherwise the service should delete itself. This is what we want.

So if RPM can delete the service itself whether it fails on step 1 or step 3, then I think this is our answer.

[Xi Zhang]

Hi Jan,

Thanks for your reply. Yes, the user should be altered it is failed. If the service runs synchronously, there is some outcome for failure. But in async operation, after the reploy process, how to get whether the service failed or not?

Thanks!