ADR for billing system

[zugao]

Summary

This ADR presents solutions for our new Event-Based BIlling

Checklist

• Try to isolate changes into separate PRs (to build a better changelog).
• Categorize the PR by setting a good title and adding one of the labels:
  change, decision, requirement/quality, requirement/functional, dependency
  as they show up in the changelog
• Link this PR to related issues if applicable.

[tobru]

Please structure the ADR document as described in https://kb.vshn.ch/app-catalog/adr/0001-architecture-decision-records.html

Other than that, I like the proposal and I think that could work. I'm a bit unsure about storing the events in CRDs because of the volume, maybe you want to test that a bit more and see where the limitations are.

[zugao]

Please structure the ADR document as described in https://kb.vshn.ch/app-catalog/adr/0001-architecture-decision-records.html

Other than that, I like the proposal and I think that could work. I'm a bit unsure about storing the events in CRDs because of the volume, maybe you want to test that a bit more and see where the limitations are.

Up to several thousands CRs I don't see an issue. And if we use one CR per service and not per event we are quite good to go. We could even generate this CR in comp-functions and later be consumed by the controller thus it will be just another object in a service. If we arrive to have hundreds of services, we will gonna have more limitations from stackgres and from kube objects (crossplane) then this CR alone.

[tobru]

@zugao Mind adding a bit more context to the ADR? I think an example of a creation and a deletion event in the "Context" section would help to set the stage on what events we have to send to Odoo for a better understanding.

Also an important detail: The instance_id has to be globally unique.

[zugao]

@zugao Mind adding a bit more context to the ADR? I think an example of a creation and a deletion event in the "Context" section would help to set the stage on what events we have to send to Odoo for a better understanding.

I added a complete example and the reasoning behind the custom resource in the Decision section.

[tobru]

A few nits here and there and a few questions, but all in all, I quite like it and I think we can go this way.

[tobru]

In the implementation phase, we also have to figure out where to get the information for spec.odoo and status.events from. Maybe we should update the ADR then when we know that.

We do store some of the required data as labels and annotations in the organization namespace on the control-plane via the Servala Portal.