Collections as regular Arvados objects » History » Revision 6
Revision 5 (Peter Amstutz, 08/08/2014 09:46 AM) → Revision 6/11 (Peter Amstutz, 08/08/2014 11:19 AM)
h1. Collections as regular Arvados objects * Collections are assigned regular UUIDs * Collections have a regular @owner_uuid@ instead * Manifest hash goes into the @portable_data_hash@ field * @manifest_text@ and @portable_data_hash@ can be edited are immutable * Can access collections on API by uuid (returns regular record) or @portable_data_hash@ (returns record containing @uuid@, @portable_data_hash@ and @manifest_text@ with @uuid@==@portable_data_hash@) ** Setting/changing @manifest_text@ on its own updates @portable_data_hash@ ** Setting/changing @portable_data_hash@ on its own fetches the manifest from Keep ** @manifest_text@ and @portable_data_hash@ have to match * Add mutable @name@, @description@, @properties@ fields * Continue to use manifest text hash (@portable_data_hash@) for crunch ** Choosers set the value to the manifest hash, record the selected collection uuid on link_uuid ** Task output continues to be a is manifest fragment or manifest hash+token hash+reader token stored in Keep ** Crunch-job continues to set job output to manifest hash+token hash ** Crunch-job creates output collection with @owner_uuid@ as the user (which means it will show up in the "home" project when #3499 is merged) * Pipeline runner is responsible for creating a collection in the target project and setting the name ** Add an optional @output_name@ field and @output_owner@ fields to the component description job submission * ** When user clicks on a link to a job completes, collection uuid, it should include is created under @output_owner@, given @output_name@, and the expected portable data hash in the URL ** If there collection uuid is a mismatch, it recorded under new @output_uuid@ field (Side note: job should throw up a warning not be marked as successful/completed until all its output and possibly tell the user what changed * Disallow content hashes in @head_uuid@ and @tail_uuid@ fields of links logs have been uploaded, see #3164) h2. Migration * Create collection objects from name links * For remaining collections, look for *can_manage* permission links and create collections assigned to the relevant user or group * Any other collections will remain owned by administrator and will have to be assigned manually (?)