Follow-up from "Document uploads development guidelines"

The following discussion from gitlab-ce!31290 should be addressed:

@marin started a discussion: (+3 comments)

marin:

I would call this Direct upload

nolith:

I wrote a bit more about direct_upload in gitlab-ce@5b86cf34e7af93d17b2a09cee26db5d356737ee0 - http://review-docs-ac-up-x7z9bn.178.62.207.141.xip.io/ce/development/uploads.html#what-does-the-direct_upload-settings-means

Given we have a direct_upload setting I'll prefer not to use that name here because of 2 reasons:

1. what we call direct_upload is implemented by Workhorse object storage acceleration and not by Workhorse disk acceleration
2. moreover direct_upload is a subset of Workhorse object storage acceleration as it will cover also the case when object storage is disabled and workhorse will still call the /authorize endpoint

marin:

Workhorse disk acceleration is not a good name because it has the name of the component (should it be GitLab Workhorse?), and disk acceleration gives little information. If Direct Upload is not an option, can we try to think of an alternative to it?

nolith:

Ok I got your point marin

The reason I used Workhorse disk acceleration is because this is the name of that feature in workhorse codebase, and being this a development guide, I was trying to point engineers into the right direction code-wise.

This are not user-facing features, but development optimization we have in place and are meant to be consumed by backend engineers and contributors.

WDYT of:

• Regular rails upload
• Workhorse disk acceleration => Disk acceleration
• Workhorse object storage acceleration => Inline object storage upload (there's no reference to 'acceleration' in workhorse codebase for this feature)

I'll prefer to avoid any reference of direct to not create confusion with direct_upload setting, but also direct object storage upload could be a good name.

We decided to merge it in the current form, and to open a follow-up issue to iterate on the naming.