-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simple POC for cross-back-end process graph processing #95
Comments
Wouldn't be a POC on the server-side be more or less the same work? I assume the code would be very similar, wouldn't it? I'm also wondering whether we should check which use case we could use for this. It needs data being available on two back-ends and the same processes so that we can actually test it. Maybe that's the first step? |
I'm indeed developing this while keeping in mind that it should port relatively easy from client-side to the aggregator.
For now, I'm just aiming for a minimal "dummy" use case: |
more explicit distinction between processes (pg+metadata) and process graphs (flat graph representation)
more explicit distinction between processes (pg+metadata) and process graphs (flat graph representation)
more explicit distinction between processes (pg+metadata) and process graphs (flat graph representation)
more explicit distinction between processes (pg+metadata) and process graphs (flat graph representation)
Triggered from debugging load_result in openeo-geopyspark-driver for Open-EO/openeo-aggregator#95
merged first iteration of POC now in master: 3a1ee85 see POC script at https://github.com/Open-EO/openeo-aggregator/blob/3a1ee8582fca9a9e1c9315708ed43680fc23ee1b/scripts/crossbackend-processing-poc.py
as illustration, excerpt of the logs of a run of this POC script:
🎉 |
I just tried to run a true cross-backend job using VITO for the main job and SentinelHub for the dependency subjob but that is currently blocked because the job result listing of SentinelHub ( {
"assets": {
"46ce6f3b-498c-48d7-af5c-d39b42ef1549/31UES_0_3/default.tif": {
"href": "https://s3.eu-central-1.amazonaws.com/com.sinergi...-d39b42ef1549/31UES_0_3/default.tif?...&X-Amz-Signature=0eaf023b011...",
"roles": [
"data"
]
},
"46ce6f3b-498c-48d7-af5c-d39b42ef1549/31UES_0_4/default.tif": {
"href": "https://s3.eu-central-1.amazonaws.com/com.sinergi...-d39b42ef1549/31UES_0_4/default.tif?...&X-Amz-Signature=7b40541efa",
"roles": [
"data"
]
}
},
"geometry": null,
"id": "d137ea10-3d36-48c3-ae15-008c130c75a9",
"links": [],
"properties": {
"datetime": null
},
"stac_version": "0.9.0",
"type": "Feature"
} Also note that it returns a The signed URL problem could relatively easy be addressed in aggregator, but I think the "Feature" instead of "Collection" problem is a lot harder to fix in VITO's |
Closing this issue for now. There are some follow up actions, e.g.
|
Follow up of #53 to have a basic POC implementation of a simple system that can split a process graph and execute it on two/multiple back-ends.
First step: instead of trying to build the whole system in the aggregator, it's maybe simpler to first build a POC that does the splitting and scheduling client side
The text was updated successfully, but these errors were encountered: