search

openEOPlatform / documentation

Documentation for openEO Platform
https://docs.openeo.cloud
Apache License 2.0
1 stars 5 forks source link

Add API & Processes profiles #81

Closed m-mohr closed 8 months ago

m-mohr commented 10 months ago

As discussed and decided upon in SAP09.

Does this need a openEO Platform Board decision @aljacob @christianbriese? Otherwise feel free to merge.

jdries commented 10 months ago

for me it's fine to merge, only synchronous job timeout of 5 minute is problematic in the sense that we'll need to make an adjustment to our production instance, while users may be relying on the current timeout. Hence this is a backwards incompatible change, which would be silly only to comply with a newly invented profile.

So not sure, either just merge it and keep the inconsistency in our backend, or drop that requirement until we have more flexible solutions for dealing with sync job timeout.

soxofaan commented 10 months ago

| 920 | POST /result > timeout | The timeout for synchronous calls is: 5 minutes |

Somewhat related to the note of @jdries : if we stick to 15 minutes (for now for practical reasons): is that worse or better than 5 minutes? Differently put: is this 5 minutes an upper boundary or lower boundary?

Can this constraint be rephrased to "default timeout", like with "expiry time of the signed URLs"?

@jdries as noted in https://github.com/Open-EO/openeo-api/issues/387 we're playing with the idea to explicitly set a timeout in the sync request from the aggregator to the (VITO) backend, so we can abort dynamically for aggregator request and leave non-aggregator requests alone, to preserve back-wards compatibility for non-aggregator usage

m-mohr commented 10 months ago

Somewhat related to the note of @jdries : if we stick to 15 minutes (for now for practical reasons): is that worse or better than 5 minutes? Differently put: is this 5 minutes an upper boundary or lower boundary?

Well, I'd say worse as it's unpredictable for a user. It may create more costs than expected and you can't cancel it either.

Can this constraint be rephrased to "default timeout", like with "expiry time of the signed URLs"?

We don't have a way to communicate the timeout right now and it is cost related, so that's not the same as the expiry time of signed URLs.

https://github.com/Open-EO/openeo-api/issues/387 doesn't really solve the issue yet wrt the default behaviour. This needs more thoughts it seems.

As all backends are non-compliant to some of the rules right now, I don't see a big short-term issue with keeping it as it is. We can re-evaluate that again in the future based on feedback or solutions that may have become available.

m-mohr commented 8 months ago

As (1) no further comments came in and (2) no one really mandated a further coordination in the Platform Board and (3) all voting Board members were part of the SAP and (4) people still reference the old outdated documents I'm now merging this. We can have further discussions if needed in separate issues/PRs.