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

[Vijay Bellur]

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. I do not see the need to have multiple 
client volume files per volume for this use case. 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.


> 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.

Thanks,
Vijay