federation of billing

[soxofaan]

quick note that all upstream back-ends should use same billing currency.

VITO backend uses credits at the moment: https://github.com/Open-EO/openeo-geopyspark-driver/blob/4c4d2ad70344ad0f0b3b9bb6abaa8491da49a187/openeogeotrellis/backend.py#L366-L369

aggregator uses EUR, but that should change to credits as well

openeo-aggregator/src/openeo_aggregator/backend.py

Lines 1113 to 1116 in 14c06e3

	def capabilities_billing(self) -> dict:
	# TODO: ok to hardcode this here, or move to config?
	return {
	"currency": "EUR",

[soxofaan]

Further possible todo's under this ticket:

• check that all upstream back-ends also report in credits currency (e.g. as part of integration tests, or raise warnings at run time, ...)

[dthiex]

also report in credits currency

@soxofaan Do you maybe remember what you meant here. If I remember correctly we have SH PUs as currency within our backend and also report this to the billing endpoint where then the translation into platform credits is done.

[soxofaan]

I think I meant that all upstream backends in the aggregator should use the same currency (credits in this case) listed under currency in capabilities doc / which is the currency used for budget, cost in batch job metadata, user info, ...

The aggregator has to list a single currency under its own capabilties, and if there is a discrepancy with upstream backends, there is a problem because there is currently no conversion happening from the cost reported by upstream backend to cost reported by aggregator.
In principle it's possible I guess to add conversion logic at aggregator level, but I'm not sure if that is a good idea, because this requires new means (new apis) to discover conversion rates properly.

[dthiex]

I see the problem but not sure how to best solve this (I am confident we report and log the correct things but some values we expose to the user might indeed be wrong/confusing). We are currently implementing some more billing metadata and will afterwards access where there are issues.

Currently we have indeed "processing units" as currency as users can also use the backend directly via their SH account without going through the platform/aggregator. For such user's credits don't mean anything.

no conversion happening from the cost reported by upstream backend to cost reported by aggregator.

I don't think this is a problem for now as you implemented some currency conversion on the billing endpoint for our backend: https://github.com/openEOPlatform/architecture-docs/issues/250#issuecomment-1187503610

[soxofaan]

Just for overview of current state

backend	currency (declared at /)
aggregator https://openeocloud.vito.be/openeo/1.1/	"credits"
eodc https://openeo.eodc.eu/openeo/1.1.0/	"EUR"
vito https://openeo.vito.be/openeo/1.1/	"credits"
sentinelhub https://jjdxlu8vwl.execute-api.eu-central-1.amazonaws.com/production/	"processing units"

Endpoints that involve currency (e.g. though a cost or budget property):

• GET / : declare currency used by back-end (if any)
• GET /me > budget: remaining budget the user has available
• POST /result set maximum budget to consume
• POST /jobs and PATCH /jobs/{job_id} set maximum budget for batch job to consume
• GET /jobs/{job_id} get actual cost (and budget) of batch job
• GET /jobs/{job_id}/estimate get cost estimate of a batch job
• POST /services and PATCH /services/{service_id} set maximum cost for service
• GET /services/{service_id} get actual cost (and budget) of a service

[soxofaan]

looping in @christophreimer @LukeWeidenwalker : what is the status of EODC back-end regarding using "credits" as currency (instead of "EUR")?

[SerRichard]

Hi, can bump the api to switch to "credits", that's not a problem. We could also add support for credits to /me and GET /jobs/{job_id}, as that's currently missing.