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@xxxxxxxxx> wrote:
On Mon, Jul 30, 2012 at 11:50 AM, Vijay Bellur <vijay@xxxxxxxxxxx> wrote:Ok.
> 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.
Say gluster volume resides on machine A and QEMU runs on machine B. In
> I do not see the need to have multiple client volume files per
> volume for this use case.
this case QEMU will use this custom client volfile.
[root@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@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.
Sure, will take a look at the tag mechanism.
> 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.
Mohan has started working on generating custom volume files. Will keep
>
>
>
>> 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.
you updated on how things turn up.
Regards,
Bharata.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
https://lists.nongnu.org/mailman/listinfo/gluster-devel
