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
