[Gluster-devel] [RFC] Generating custom volume files for gluster volumes

[Bharata B Rao]

On Mon, Jul 30, 2012 at 11:50 AM, Vijay Bellur <vijay at gluster.com> wrote:
> On 07/26/2012 10:28 AM, Bharata B Rao wrote:
>
>>
>> Its already possible to specify a custom extension to the volume name
>> and glusterd picks the appropriate volume file. For eg, for a volname
>> of test.cust, glusterd is capable of picking test.cust.vol. We plan to
>> piggy back on this feature and name the custom volume files with
>> .custom extension.
>>
>> Typical gluster CLI commands needed could be like this:
>>
>> gluster> volume regenerate testvol custom --without-io-cache
>> --with-quick-read
>>
>> This would create testvol.custom without io-cache and with quick-read
>> xlators.
>>
>> This is just an example and not really cast in stone. Need community's
>> opinion on this. Should we use existing options like "volume set" or
>> invent new ones ?
>>
>
> I would prefer that we re-use "volume set" for the purpose of re-generating
> volume files.

Ok.

> I do not see the need to have multiple client volume files per
> volume for this use case.

Say gluster volume resides on machine A and QEMU runs on machine B. In
this case QEMU will use this custom client volfile.

[root at bharata test]# cat test.cust.vol
volume test
    type protocol/client
    option remote-host A
    option remote-subvolume /test
    option transport-type tcp
end-volume

Note that instead of the custom client volfile, I could have used the
default client volfile too.

Next if QEMU migrates to A, then it will use this volume file:

[root at bharata test]# cat test.rpcbypass.vol
volume test
    type storage/posix
    option directory /test
    option volume-id b1252bd2-410c-4b60-9807-57a61d43b356
end-volume

Hence there is a need to have multiple volume files for a given volume.

> Using the same volume for storing VM images and
> other data might not be a widespread use case. As such, the workload on the
> volume would be homogeneous and customizing the default volume file to serve
> this workload would be desirable.
>
> We are also evolving the notion of tags for volumes. A tag would provide the
> ability to bundle a bunch of "volume set" commands under an alias. A tag
> when applied to a volume would result in re-generation of volume files and
> the end result would be the same as having applied each of the volume set
> commands individually. You can probably define a tag and use that for the VM
> image store volume.

Sure, will take a look at the tag mechanism.

>
>
>
>> Should we allow such flexibility when creating volumes or should we
>> provide such capability only when regenerating volume files  for a
>> given volume ?
>
>
> It might be good to allow such flexibility while creating volumes too. This
> would mean that we will have to introduce additional keywords or provide
> switches for volume creation. Instead of adding new keywords to volume
> create, we can also look at enhancing tags to provide this behavioural
> change for a volume upon application of the tag. The feature page for volume
> tagging would be up for RFC shortly.

Mohan has started working on generating custom volume files. Will keep
you updated on how things turn up.

Regards,
Bharata.