Proposal: Changing `CREATE_VOLUME` and `CREATE_BLOCK` to `CREATE_DISK`.

[Chun-Hung Hsiao <ch...@mesosphere.io>]

Hi folks,

*TL;DR*

I'm proposing a breaking API change on experimental offer operations, as
shown in the review request:
https://reviews.apache.org/r/67779/
Reasons:
1. "Volume" is overloaded and leads to conflicting/inconsistent naming.
2. The concept of "PATH" disks does not exist in CSI, which could be
problematic.

Please provide feedbacks or raise any concern you have. Thanks!

*Introduction*

Mesos 1.5 introduced four new operations for better storage support through
CSI. These operations are:
  * CREATE_VOLUME converts RAW disks to MOUNT or PATH disks.
  * DESTROY_VOLUME converts MOUNT or PATH disks back to RAW disks.
  * CREATE_BLOCK converts RAW disks to BLOCK disks.
  * DESTROY_BLOCK converts BLOCK disks back to RAW disks.
However, the following two issues are raised for these operations.

*Naming/terminology inconsistency*

In Mesos we used to roughly use the term "volume" to refer to persistent
volumes. For example, we have the following endpoints:
http://mesos.apache.org/documentation/latest/persistent-volume/#unversioned-operator-http-endpoints
And we have a corresponding ACLs: `ACL.CreateVolume` and
`ACL.DestroyVolume`.
But, the `CREATE_VOLUME` and `DESTROY_VOLUME` operations are not related to
persistent volume at all, and it becomes hard to come up with intuitive
names for the corresponding ACLs.

On the other hand, we distinguish "volumes" from "blocks," which is
incosistent with CSI. CSI has "block volumes" and "mount volumes," so when
an operator with CSI knowledge want to use Mesos, the names may confuse
them.

Since these operations are still experimental, and AFAIK there has been no
3rdparty framework that uses these operations yet except for us, I'd like
to propose a breaking API change to rename and combine these operations
into `CREATE_DISK` and `DESTROY_DISK`. Furthermore, we could refine the use
of "volume" to refer to "ROOT/PATH/MOUNT/BLOCK disk resources with metadata
that could be used by containers."

*PATH disks do not exist in CSI*

PATH disks are used to split local disks into smaller chunks so tasks can
use them concurrently and independently. We have isolators such as
"disk/du" or "xfs/disk" to enforce their usage capacity. This PATH concept,
however, does not exist in CSI, and this could be prone to future CSI
changes. For example, to enforce usage, we will need to directly interact
with the filesystem on top of CSI volumes without involving CSI plugins.
Also, when we support non-local CSI volumes (such as EBS volumes) in the
future, those volumes won't be able to be split into small chunks to be
used on different agents.

Therefore, I propose that we should remove PATH support for these storage
operations.

Best,
Chun-Hung