Project

General

Profile

Bug #14710

Updated by Peter Amstutz about 5 years ago

Child containers are determined by querying for container requests where requested_by_container_uuid matches the parent container.    This does not work for federated workflows, because (a) containers run on remote clusters don't set @requested_by_container_uuid@ and (b) even if it was set, we don't have an easy way to query remotes it (requires either #14374 or generalizing javascript multi-site search feature). 

 Solution: 

 # When controller creates a remote container request, For (a) The arvados-cwl-runner does know which containers it can supply @requested_by_container_uuid@ 
 # Controller records is tracking. so it could explicitly update the uuid container record with a list of child containers, similar to the remote container request, and saves runtime_status feature. 

 Proposal: 

 # Add a cache copy @child_requests@ field to @container@ which has an array (array or jsonb type) of container request record in the local database with the appropriate @requested_by_container_uuid@ uuids  
 # The client can filter In @controller@, when handling a @container_request@ create from a container, update @child_requests@ 
 # Workbench displays @child_requests@ instead of searching on @requested_by_container_uuid@ in the local database and get both local and remote container requests. 
 # When a client makes a list or get request that returns remote objects, fetch the latest records from the remote cluster and merge the updated records into the response.    (And update the cached copy?) 

 What API server should the owner_uuid by on the cache copy? use @child_requests@ for priority propagation (?)

Back