New format for Volume create request

[aravindavk]

Current Volume Create request format is very limited since it converts
the list of bricks into sub volumes based on other parameters and
order of bricks. With new format, each sub volume can have its own type
and list of bricks.

For example, to create distribute replicate volume,

Existing,

{
    "name": "gv1",
    "replica": 2,
    "bricks": [
        "b4e2a4a5-103f-4ae7-8545-706b7c5039e9:/bricks/b1", 
        "72b66b1e-e29c-450a-a4af-bfc8499aae54:/bricks/b2", 
        "b0e0b26c-fecc-4e24-8edc-f2f328258301:/bricks/b3", 
        "9fd10082-84b7-431d-a58c-9a6d060fd7cd:/bricks/b4"
    ],
    "transport": "tcp"
}

Proposed,

{
    "name": "gv1",
    "subvols": [
        {
            "name": "s1",
            "type": "replicate",
            "bricks": [
                {"nodeid": "b4e2a4a5-103f-4ae7-8545-706b7c5039e9", "path": "/bricks/b1"}, 
                {"nodeid": "72b66b1e-e29c-450a-a4af-bfc8499aae54", "path": "/bricks/b2"}
            ]
        },
        {
            "name": "s2",
            "type": "replicate",
            "bricks": [
                {"nodeid": "b0e0b26c-fecc-4e24-8edc-f2f328258301", "path": "/bricks/b3"}, 
                {"nodeid": "9fd10082-84b7-431d-a58c-9a6d060fd7cd", "path": "/bricks/b4"}
            ]
        }
    ],
    "transport": "tcp"
}

In case of Arbiter volume,(Note, bricks order is not strict)

{
    "name": "gv1",
    "subvols": [
        {
            "name": "s1",
            "type": "arbiter",
            "bricks": [
                {"nodeid": "b4e2a4a5-103f-4ae7-8545-706b7c5039e9", "path": "/bricks/b1"}, 
                {"nodeid": "72b66b1e-e29c-450a-a4af-bfc8499aae54", "path": "/bricks/b2"},
                {"nodeid": "59a6033e-07c3-49bb-92a0-f38c8dfbdb0a", "path": "/bricks/b3", "arbiter": true}
            ]
        },
        {
            "name": "s2",
            "type": "arbiter",
            "bricks": [
                {"nodeid": "b0e0b26c-fecc-4e24-8edc-f2f328258301", "path": "/bricks/b4"}, 
                {"nodeid": "9fd10082-84b7-431d-a58c-9a6d060fd7cd", "path": "/bricks/b5", "arbiter": true},
                {"nodeid": "1b9f7313-a85b-46ba-a2ff-e9620f0f06bb", "path": "/bricks/b6"}
            ]
        }
    ],
    "transport": "tcp"
}

Let me know if any changes required to the format or any new fields
required.

Expected changes

• REST Client package, CLI to REST Client communication remains same
• CLI changes while displaying volinfo
• Volinfo struct changes
• Volume commands changes while accessing information
• REST API documentation changes

[aravindavk]

@amarts @kshlm @atinmu @prashanthpai please provide inputs to this change.

[amarts]

This is what I had in mind. Just make sure more depth than 1 (ie, DHT -> AFR, DHT -> EC) subvolume (ie, DHT -> AFR -> STRIPE etc) in the json for future compatibility.

[kshlm]

For the brick object, instead of an explicit "arbiter" member, we should probably have a generic string:string dictionary, called opts or something else. We should also add the same dict to the subvolumes. This would allow things like marking hot and cold tiers. This should help keep our internal structs more extensible.

Otherwise looks good.

[amarts]

I see the need for more fields for sure:

template: for identifying which volgen template to use.
options: think of this as gluster volume profile option. But one can send this in API itself.

[atinmu]

What MVP milestone we should tag this to? @aravindavk @kshlm @prashanthpai

[atinmu]

Checklist

• ReST APIs availibility in wiki
• CLI commands
• Sufficient logging
• Availibility of metrics data if applicable
• Xlator options table upto date?
• Test cases & test coverage of the functionality