[Spce-user] Prepaid not working

[Alex Lutay]

Hi,

Yes you are right. So far is it really a show stopper here? ;-)

I would say the feature is about public
https://github.com/sipwise/ngcpcfg repo.

It already has built-in YML validation based on
https://github.com/eserte/p5-Kwalify
Try "ngcpcfg --validate check".
(BTW, I am considering to enable validation by default
in 'check' action, any feedback here?)

Since the library is no longer supported by upstream,
we can fork it and add the check for product type there.

At the end 'ngcpcfg build/apply' can inform users about changed
options which have no effect on the current product type.

>From my side I will add default for all options and
mark all options as "product: [CE , PRO, CARRIER]"
(since the config schema repo is private).
So far I need the help with Perl library here.

In the past we were trying to separate the options for different
products. So far a lot of race conditions happened back to that time
(as PRO features are became available for CE, etc). A lot of human
mistakes happened and overall product complexity and resources to test
all the cases in all the product types was growing and growing.

We have changed the strategy here...

The general strategy for Sipwise is Carrier the main platform,
fully scalable and extremely fast. PRO is kind of degraded Carrier,
where all roles are operates by two hosts only. CE is a degraded PRO,
where we lost the peer and operates by one host only.

We are not (yet) there while we are moving.

The license server is exactly the necessary part for those purpose,
as PRO and Carrier codebase is 99% identical. As for CE it is not
fully possible due to GPL restrictions. So far we are still trying to
share with community everything we can, even supporting copy of
components like sems in GPL and non-GPL versions.

Those strategy allows us to release the high quality software
with limited amount of resources in a very fast way.
Also Sipwise supports 3 LTS releases for 3 years in parallel.

Additionally supporting 3 different products here is a triple expensive.
It increases the matrix of fixes/tests dramatically.
Which decreases the product quality, makes community unhappy and
slowdown Sipwise.

I hope you understand the situation. Also, we are open for improvements!
CE is a "community edition", it will not survive without community.
For some reason there are no emails in spce-dev@ queue for years.
The pull requests are also happen for rtpengine repo only.

Can we change this? IMHO, yes.

Back to original topic:
* hiding (aka removing) YML options is a bad idea, we tried it.
* force users edit YMLs is bad idea also, a lot of human mistakes here.
We are trying to minimise them using validation schema nowadays.
* generally speaking, editing YML files doesn't provide all the
necessary information:
  * is the options in default state or changed?
  * what is the purpose of the option? Option description?
  * is the option dependency? if you enable A, maybe you have to enable
something else as well?
  * what about options validation
  * what is the impact of changing the option? what will be restarted?

I can continue the list above. None of the requirements above can be
solved with plain text editing :-(
IMHO some GUI/WEB is necessary here instead of plain file editing.
It can perform all necessary validation and show all the additional
information and ALSO it can hide PRO options on CE product.

This is a way we are moving now, so far we are far from the happy end.

So, pull requests are welcome! Have fun!

On 08/23/2018 01:31 PM, Jon Bonilla (Manwe) wrote:
...
>> Pull requests are welcome here! ;-)
> 
> AFAIR templates and cfg-schema are private repos. Aren't they?
-- 
Alex Lutay