Collections as regular Arvados objects » History » Version 9
Peter Amstutz, 10/03/2014 02:06 AM
1 | 1 | Peter Amstutz | h1. Collections as regular Arvados objects |
---|---|---|---|
2 | |||
3 | 9 | Peter Amstutz | (Implemented August 2014 #3036) |
4 | 8 | Tom Clegg | |
5 | 1 | Peter Amstutz | * Collections are assigned regular UUIDs |
6 | 5 | Peter Amstutz | * Collections have a regular @owner_uuid@ instead |
7 | 1 | Peter Amstutz | * Manifest hash goes into the @portable_data_hash@ field |
8 | 6 | Peter Amstutz | * @manifest_text@ and @portable_data_hash@ can be edited |
9 | * 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@) |
||
10 | ** Setting/changing @manifest_text@ on its own updates @portable_data_hash@ |
||
11 | ** Setting/changing @portable_data_hash@ on its own fetches the manifest from Keep |
||
12 | ** @manifest_text@ and @portable_data_hash@ have to match |
||
13 | 1 | Peter Amstutz | * Add mutable @name@, @description@, @properties@ fields |
14 | 7 | Peter Amstutz | ** Use same logic for names/descriptions as already exist for other Arvados objects |
15 | 1 | Peter Amstutz | * Continue to use manifest text hash (@portable_data_hash@) for crunch |
16 | ** Choosers set the value to the manifest hash, record the selected collection uuid on link_uuid |
||
17 | 6 | Peter Amstutz | ** Task output continues to be a manifest fragment or manifest hash+token stored in Keep |
18 | ** Crunch-job continues to set job output to manifest hash+token |
||
19 | ** 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) |
||
20 | * Pipeline runner is responsible for creating a collection in the target project and setting the name |
||
21 | ** Add an @output_name@ field to the component description |
||
22 | * When user clicks on a link to a collection uuid, it should include the expected portable data hash in the URL |
||
23 | ** If there is a mismatch, it should throw up a warning and possibly tell the user what changed |
||
24 | * Disallow content hashes in @head_uuid@ and @tail_uuid@ fields of links |
||
25 | 4 | Peter Amstutz | |
26 | 3 | Peter Amstutz | h2. Migration |
27 | 1 | Peter Amstutz | |
28 | 7 | Peter Amstutz | * Update schema to add @name@, @description@, @properties@ columns |
29 | * Convert name links to collection objects owned by @tail_uuid@ and delete the name links |
||
30 | * For remaining collections not accessible through name links, look for *can_read* permission links and create collections owned to the relevant user or group |
||
31 | * Any other collections will remain owned by system user and will have to be assigned manually (?) |
||
32 | * Update links (other than name or permission links) that point to a manifest hash to point to an appropriate collection uuid instead |