Refactor billing

[zugao]

Summary

Currently we are getting data for billing from the workloads (deployments and statefulsets) special label appcat.io/billing=true. This approach proved to be ineffective for some services such as VSHNPostgreSQL which is managed by Stackgres. Unfortunately the operator sometimes is managing the pods directly, by passing the workload. In this particular case we end up without the necessary label in the pod definition.

This new approach manages differently the billing architecture. If previously we were having one prometheus rule which would gather unnecessarily difficult specific data, now we have one rule per each instance namespace and it is managed directly by the composition function where we get reliable data from the source.

Checklist

• Categorize the PR by setting a good title and adding one of the labels:
  bug, enhancement, documentation, change, breaking, dependency
  as they show up in the changelog
• Update tests.
• Link this PR to related issues.

[Kidswiss]

Have you tested this with an appuio managed scenario as well?

[zugao]

Have you tested this with an appuio managed scenario as well?

I am deploying now in a test managed cluster and will confirm that everything is fine.

[Kidswiss]

Have you tested this with an appuio managed scenario as well?

I am deploying now in a test managed cluster and will confirm that everything is fine.

The query to generate the data is slightly different, we add another label: https://github.com/vshn/component-appcat/blob/master/component/promql/metering_managed.promql#L14

The value is directly set via the component. You need to add some logic to cover that case here as well.

[zugao]

The value is directly set via the component. You need to add some logic to cover that case here as well.

Indeed I take the sales order from the composition extra config map. This should do the job

[zugao]

Tested in kind with APPUiO Managed (+ sales_order label) and without (- sales_order label).

[Kidswiss]

I just found something concerning the AddServiceBillingLabel step, which can break nextcloud or keycloak provision:

it restarts the instance 1 minute after the initial deployment, so we should also remove that function as soon as possible.

[zugao]

I just found something concerning the AddServiceBillingLabel step, which can break nextcloud or keycloak provision:

it restarts the instance 1 minute after the initial deployment, so we should also remove that function as soon as possible.

Tested if it would restart the pod, it doesn't so I removed it!

[Kidswiss]

Just one more thing to simplify, the rest LGTM