We have a bunch of sharing features. We should have a page on the documentation site that explains them all.

Diff it against @update-gitolite.rb@—there's a lot of shared code.

Add "username" attribute to users table. * Can be null. * Unique. * Starts with alpha. Contains only alphanum. * Only admin can change. (Could change in future, but simplifies for now.) * Migration: for active users, copy repository name if there is one, otherwise assign one based on email address. For inactive users, leave null.

* User can create a repository with owner_uuid==current_user.uuid but not with any other owner_uuid (unless current_user.is_admin) * owner_uuid must refer to a user, not a group (even if current_user.is_admin) * Permission summary provided to gitolite grants repository owner RW+ permission * Export repository names as "username/reponame" (assuming this is convenient for gitolite permission-sync script). * Update gitolite permission-sync script.

* On manage account page (at least for now) * Add new repository -> dialog box (or inline, if easier) ** Show note that repositories cannot be renamed ** Show note that it will take a minute or two before "git clone" will work (aside/future: can Workbench get feedback from the git system somehow so it can say "pending" on new repos?)

* Repository with name=bar, owned by user with username=foo, is "{base}/foo/bar.git" * name cannot be null. * {owner_uuid, name} is unique. * name starts with alpha, contains only alphanum. * Migrate existing repositories to owner_uuid=system_user_uuid. These will continue to be available at "{base}/foo.git".

This is an existing bug in the API server.

Disk list should look roughly like: <pre> [{'autoDelete': True, 'boot': True, # image.extra['selfLink'] 'initializeParams': {'sourceImage': u'https://www.googleapis.com/compute/v1/projects/curoverse-production/global/images/ourImageName'}, 'type': 'PERSISTENT'}, {'autoDelete': True, # This is an arbitrary name we choose. 'deviceName': 'data-ssd', # disktype.extra['selfLink'] 'initializeParams': {'diskType': u'https://www.googleapis.com/compute/v1/projects/curoverse-production/zones/us-central1-a/diskTypes/local-ssd'}, 'type': 'SCRATCH'}] </pre> Add this as @ex_disks_gce_struct@ to @self.create_kwargs@.

The latter needs the former to install the ping URL file before it can do anything. The current setup works, but it has to wait for get-meta-data to be invoked from its every-five-minutes cron job.

The disk is at @/dev/disk/by-id/google-FOO@, where @FOO@ is a string we can specify at node creation time. /tmp is what we use on AWS. Let's make @FOO@ == tmp

See #5502 comments for background.

The Keepstore TrashCollector is a module which recycles trashable blocks asynchronously. The interface is: The TrashCollector.New() function creates and returns a TrashCollector object, and launches a Recycle goroutine which waits for trash requests. Garbage collection is triggered by the Start(trashlist) method. trashlist is a slice of block hashes, and is sent over a channel to the Recycle goroutine. Recycle loops over the list of blocks to be deleted and calls vol.Delete on each one.

cf. #5381

All throughout the marketing literature and documentation we describe Keep as content addressable. Technically, I believe that a Content Address is a hash, but it would be more clear and consistent if the UI also referred to it as a Content Address rather than a Content Hash. Also, now that collections can be updated and versioned, the GUID is important. Right now the GUID most clearly appears in the URL. To make it more obvious to users that a collection has both a Content Address and a GUID, perhaps the GUID should be listed in the description box. Finally, since people sometime copy GUIDs and Content Addresses, it would be nice to have a copy gesture right in the UI (e.g. clicking on the item could copy or small button).

See "story note-8":https://arvados.org/issues/5034#note-8 for implementation discussion.