Configurable options are persisted per service

[kwm365]

Looking at how configurable options reach provisioning on current main
(commit acf0292), and I want to check whether I'm reading this correctly
or missing something.

What I see:

• Selected values are persisted per service in service_config_options
  and are picked up by pricing (CartService) and by upgrades
  (UpgradeService).
• No server module appears to read them. A grep for ServiceConfigOption
  across modules/ returns nothing, while the same grep in app/ matches.
• PanelicaModule::createAccount() provisions from the product's JSON
  config using the res_* limits, and creates one shared plan
  pnlcs-p<id> per product rather than per service.

If that is right, an option such as "RAM: 4 GB" changes the invoice
amount but not the provisioned account.

Questions:

1. Is passing configurable option values into server modules planned,
   or are options currently intended as a pricing mechanism only?
2. Would that require per-service plans instead of the current
   per-product plan, or is there another path you have in mind?
3. Is there a supported way to do this from a hook today? I see
   AfterModuleCreate, but the module's HTTP helpers are private, so
   it would mean a separate API client. And I don't see a hook point
   for option changes on an existing service.

Same question applies to product add-ons, which look like they have the
same gap.

Happy to help test whatever direction you take.

regards
Martin

[Panelica]

Hi kwm365,

Sorry this went unanswered for so long, and thank you for the careful reading. We have also replied to you in more detail by email (through your support ticket); here is the public part, so others looking at the same question can see it.

You read it correctly:

1. Today configurable options are a pricing mechanism only. The chosen values are stored per service in service_config_options and used by the cart, renewals and upgrades, but no server module reads them. So "RAM: 4 GB" changes the invoice and not the account. Product add-ons have the same gap: no server module reads them either. There is no fixed design for passing them to modules yet.

2. Per-product vs per-service plans. Yes. In managed mode the Panelica module builds one plan per product (pnlcs-p<id>), so every service on that product lands on the same limits. Honouring options would need something per service, for example a plan derived from the product's managed plan plus the chosen options. We are open to other approaches if you see a cleaner one.

3. Hooks. AfterModuleCreate receives the service, but the module's HTTP helpers are private, so today it would indeed mean a separate API client. There is no hook for option changes because PNLCS has no flow that changes options on an existing service: options are set when the order is placed, and an upgrade keeps or drops them.

If you would like to take this on, we would be glad to see a proposal here first and then a pull request. As the README says, PNLCS moves forward largely with help from the people who use it. If a change fits the existing architecture and works for current installs, we will gladly review and merge it, with credit. The contributing guide and module guide are good starting points.

Thanks again for the help.

Panelica Team