Bharata,<div> This might be redundant, but just checking - have you reviewed the licensing impact with the rpc bypass? storage/posix is GPLv3.</div><div><br></div><div>Thanks,</div><div>Avati<br><br><div class="gmail_quote">
On Mon, Jul 30, 2012 at 2:11 AM, Bharata B Rao <span dir="ltr"><<a href="mailto:bharata.rao@gmail.com" target="_blank">bharata.rao@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, Jul 30, 2012 at 11:50 AM, Vijay Bellur <<a href="mailto:vijay@gluster.com">vijay@gluster.com</a>> wrote:<br>
> On 07/26/2012 10:28 AM, Bharata B Rao wrote:<br>
><br>
>><br>
>> Its already possible to specify a custom extension to the volume name<br>
>> and glusterd picks the appropriate volume file. For eg, for a volname<br>
>> of test.cust, glusterd is capable of picking test.cust.vol. We plan to<br>
>> piggy back on this feature and name the custom volume files with<br>
>> .custom extension.<br>
>><br>
>> Typical gluster CLI commands needed could be like this:<br>
>><br>
>> gluster> volume regenerate testvol custom --without-io-cache<br>
>> --with-quick-read<br>
>><br>
>> This would create testvol.custom without io-cache and with quick-read<br>
>> xlators.<br>
>><br>
>> This is just an example and not really cast in stone. Need community's<br>
>> opinion on this. Should we use existing options like "volume set" or<br>
>> invent new ones ?<br>
>><br>
><br>
> I would prefer that we re-use "volume set" for the purpose of re-generating<br>
> volume files.<br>
<br>
</div>Ok.<br>
<div class="im"><br>
> I do not see the need to have multiple client volume files per<br>
> volume for this use case.<br>
<br>
</div>Say gluster volume resides on machine A and QEMU runs on machine B. In<br>
this case QEMU will use this custom client volfile.<br>
<br>
[root@bharata test]# cat test.cust.vol<br>
volume test<br>
type protocol/client<br>
option remote-host A<br>
option remote-subvolume /test<br>
option transport-type tcp<br>
end-volume<br>
<br>
Note that instead of the custom client volfile, I could have used the<br>
default client volfile too.<br>
<br>
Next if QEMU migrates to A, then it will use this volume file:<br>
<br>
[root@bharata test]# cat test.rpcbypass.vol<br>
volume test<br>
type storage/posix<br>
option directory /test<br>
option volume-id b1252bd2-410c-4b60-9807-57a61d43b356<br>
end-volume<br>
<br>
Hence there is a need to have multiple volume files for a given volume.<br>
<div class="im"><br>
> Using the same volume for storing VM images and<br>
> other data might not be a widespread use case. As such, the workload on the<br>
> volume would be homogeneous and customizing the default volume file to serve<br>
> this workload would be desirable.<br>
><br>
> We are also evolving the notion of tags for volumes. A tag would provide the<br>
> ability to bundle a bunch of "volume set" commands under an alias. A tag<br>
> when applied to a volume would result in re-generation of volume files and<br>
> the end result would be the same as having applied each of the volume set<br>
> commands individually. You can probably define a tag and use that for the VM<br>
> image store volume.<br>
<br>
</div>Sure, will take a look at the tag mechanism.<br>
<div class="im"><br>
><br>
><br>
><br>
>> Should we allow such flexibility when creating volumes or should we<br>
>> provide such capability only when regenerating volume files for a<br>
>> given volume ?<br>
><br>
><br>
> It might be good to allow such flexibility while creating volumes too. This<br>
> would mean that we will have to introduce additional keywords or provide<br>
> switches for volume creation. Instead of adding new keywords to volume<br>
> create, we can also look at enhancing tags to provide this behavioural<br>
> change for a volume upon application of the tag. The feature page for volume<br>
> tagging would be up for RFC shortly.<br>
<br>
</div>Mohan has started working on generating custom volume files. Will keep<br>
you updated on how things turn up.<br>
<br>
Regards,<br>
Bharata.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
<a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
</div></div></blockquote></div><br></div>