Atomic/reliable tariff plan update

[Jacek Konieczny]

It seems I am missing something…

Lets say I have a working SIP service using CGRates for real-time rating of the calls. It works properly with some tariff plan, but I need to  update the tariff.  Let's say remove some special destinations.

If I just use cgr-loader to load the new tariff plan – old destinations will still be there and the rating will be wrong.  I could use cgr-loader to remove the old tariff plan objects first… but then there will be time without any tariff plan loaded. Or some inconsistent state.

Am I supposed to shut down my service, flush cgrates database and make a clean load of tariff plan any time anything changes?

Shouldn't be there a way to atomically replace one config with another? Am I supposed to implement any safe config updates myself using the API?

Greets,

Jacek

[Dan Christian Bogos]

Hi Jacek,

Please see answers inline ...

On 12.05.21 14:25, Jacek Konieczny wrote:

It seems I am missing something…

Lets say I have a working SIP service using CGRates for real-time rating of the calls. It works properly with some tariff plan, but I need to  update the tariff.  Let's say remove some special destinations.

Would recommend using ActivationTime within your RatingProfile, pointing to a new RatingPlan. In this way one RatingPlan is independent (and atomic) from another.

DanB

If I just use cgr-loader to load the new tariff plan – old destinations will still be there and the rating will be wrong.  I could use cgr-loader to remove the old tariff plan objects first… but then there will be time without any tariff plan loaded. Or some inconsistent state.

Am I supposed to shut down my service, flush cgrates database and make a clean load of tariff plan any time anything changes?

Shouldn't be there a way to atomically replace one config with another? Am I supposed to implement any safe config updates myself using the API?

Greets,

Jacek

--
You received this message because you are subscribed to the Google Groups "CGRateS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cgrates+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cgrates/d5fac450-6a57-4cf7-85fc-7d7277c12746n%40googlegroups.com.

[Marcin Kowalczyk]

Hi Dan,

As 4 years passed since time Jacek asked for this ;-) Is there more reliable way to do atomic rating plan updates? I asume there can be a case where particular rating profile is removed but as it persisted in DB with old activation time that is concidered as valid. 

Regards

Marcin

[Armir Veliaj]

Hi Marcin,

This is the right approach to use. Based on the CGRateS architecture, we can’t think of a more logical or safer alternative.
If you have any ideas or recommendations, please feel free to share them.


Thanks,
Armir

[Marcin Kowalczyk]

Hi,

 I can see at least one potential hole in atomic update of rating plan - when you need to remove particular entries from RatingPlan (not tested this one). 

Let's say on 01.01.2026 00:00:01  by accident I've created rating profile with *any and cost *free. Reloading pricing  cgr-loader with activation 01.01.2025 01:01:10 with removed faulty profile will do nothing as *any will still be in place and will be active as activation time passed, and no newer entries exists. Only way to get out of this situation is to remove it with API - if you knew about this error.

I think something like extra API method "deactivate all RP older than XYZ maybe would do the trick? 

[Armir Veliaj]

Hi Marcin,

Adding an API to deactivate all RatingProfiles based on activation time would probably introduce more risk of accidentally removing RatingProfiles that we don't intend to remove, just for the sake of fixing an error in the rating configuration. It's not practical to remove all rating plans just because of misconfigurations when you can fix the issue directly inside the rating  itself. For specific RatingProfile or RatingPlan removals, you can use the existing APIs: APIerSv1.RemoveRatingProfile and APIerSv1.RemoveRatingPlan.


And for having as atomic rating plan updates a better approach to prevent inconsistencies during updates, is to use cache as a buffer. First, trigger CGRateS to load the rating plan into cache (by running a cost command or any api that uses that rating plan). Once it's in cache, CGRateS operates entirely from cache. While the system runs from cache, you can safely update your rating plan in DataDB (from CSV or StoreDB) and removing old entries and loading new ones. When you're done with the updates, reload the cache using CacheSv1.Clear and CacheSv1.ReloadCache. This makes the rating plan switch atomic and suit your scenario.

Thanks,
Armir

[Marcin Kowalczyk]

Hi, 

IMHO the whole point of being atomic updare is to remove everything that does not belong to current db/csv state. 

To view this discussion visit https://groups.google.com/d/msgid/cgrates/ddbbf640-fa97-476a-bc86-a0759a1cd341n%40googlegroups.com.