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

[Anand Avati]

Bharata,
 This might be redundant, but just checking - have you reviewed the
licensing impact with the rpc bypass? storage/posix is GPLv3.

Thanks,
Avati

On Mon, Jul 30, 2012 at 2:11 AM, Bharata B Rao <bharata.rao at gmail.com>wrote:

> 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.
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20120730/42dd9004/attachment-0003.html>