<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jul 28, 2013 at 12:02 PM, Vijay Bellur <span dir="ltr"><<a href="mailto:vbellur@redhat.com" target="_blank">vbellur@redhat.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 07/29/2013 12:18 AM, Anand Avati wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<br>
<br>
On Sun, Jul 28, 2013 at 11:18 AM, Vijay Bellur <<a href="mailto:vbellur@redhat.com" target="_blank">vbellur@redhat.com</a><br></div><div class="im">
<mailto:<a href="mailto:vbellur@redhat.com" target="_blank">vbellur@redhat.com</a>>> wrote:<br>
<br>
Hi All,<br>
<br>
There was a recent thread on fedora-devel about bloated glusterfs<br>
dependency for qemu:<br>
<br></div>
<a href="https://lists.fedoraproject." target="_blank">https://lists.fedoraproject.</a>__<u></u>org/pipermail/devel/2013-July/<u></u>__186484.html<div class="im"><br>
<<a href="https://lists.fedoraproject.org/pipermail/devel/2013-July/186484.html" target="_blank">https://lists.fedoraproject.<u></u>org/pipermail/devel/2013-July/<u></u>186484.html</a>><br>
<br>
As of today, we have the following packages and respective primary<br>
constituents:<br>
<br>
1. glusterfs - contains all the common xlators,<br>
libglusterfs, glusterfsd binary & glusterfs symlink to glusterfsd.<br>
2. glusterfs-rdma - rdma shared library<br>
3. glusterfs-geo-replication - geo-rep related objects<br>
4. glusterfs-fuse - fuse xlator<br>
5. glusterfs-server - server side xlators, config files<br>
6. glusterfs-api - libgfapi shared library<br>
7. glusterfs-resource-agents - OCF resource agents<br>
8. glusterfs-devel - Header files for libglusterfs<br>
9. glusterfs-api-devel - Header files for gfapi<br>
<br>
As far as qemu is concerned, qemu depends on glusterfs-api which in<br>
turn is dependent on glusterfs. Much of the apparent bloat is coming<br>
from glusterfs package and one proposal for reducing the dependency<br>
footprint of consumers of libgfapi could be the following:<br>
<br>
a) Move glusterfsd and glusterfs symlink from 'glusterfs' to<br>
'glusterfs-server'<br>
b) Package glusterfsd binary and glusterfs symlink in 'glusterfs-fuse'<br>
<br>
<br>
<br>
Does that mean glusterfsd is in glusterfs-server or glusterfs-fuse? It<br>
is probably sufficient to leave glusterfs-fuse just have fuse.so and<br>
</div><a href="http://mount.glusterfs.in" target="_blank">mount.glusterfs.in</a> <<a href="http://mount.glusterfs.in" target="_blank">http://mount.glusterfs.in</a>><br>
</blockquote>
<br>
With this model, glusterfsd is part of both -server and -fuse. I don't like this idea entirely, for a different scheme see below.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Another model can be:<br>
<br>
0. glusterfs-libs.rpm - libglusterfs.so libgfrpc.so libgfxdr.so<br>
1. glusterfs (depends on glusterfs-libs) - glusterfsd binary, glusterfs<br>
symlink, all common xlators<br>
2. glusterfs-rdma (depends on glusterfs) - rdma shared library<br>
3. glusterfs-geo-replication (depends on glusterfs) - geo-rep related<br>
objects<br>
4. glusterfs-fuse (depends on glusterfs) - fuse xlator, mount.glusterfs<br>
5. glusterfs-server (depends on glusterfs) - server side xlators, config<br>
files<br>
6. glusterfs-api (depends on glusterfs-libs) - libgfapi.so and api.so<br>
7. glusterfs-resource-agents (depends on glusterfs)<br>
8. glusterfs-devel (depends on glusterfs-libs) - header files for<br>
libglusterfs<br>
9. glusterfs-api-devel (depends on glusterfs-api) - header files for gfapi<br>
<br>
This way qemu will only pick up libgfapi.so libglusterfs.so libgfrpc.so<br>
and libgfxdr.so (the bare minimum to "just execute") for the binary to<br>
load at run time. Those who want to store vm images natively on gluster<br>
must also do a 'yum install glusterfs' to make gfapi 'useful'. This way<br>
Fedora qemu users who do not plan to use gluster will not get any of the<br>
xlator cruft.<br>
</blockquote>
<br></div>
I like the idea about users of qemu not having to do with non-required glusterfs cruft but with this model we still have glusterfsd binary being pulled in for consumers who want libgfapi alone.</blockquote><div><br></div>
<div>How? libgfapi depends only on glusterfs-libs. Whereas glusterfsd is in glusterfs rpm.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Having the 'glusterfs' package contain only common xlators and moving glusterfs/glusterfsd binaries to a different package that depends on 'glusterfs' package might make it even better for consumers of libgfapi.</blockquote>
<div><br></div><div>Separating glusterfsd and xlators is of little use. libgfapi is an exception (for packaging of qemu, samba etc.) Since libgfapi depends only on glusterfs-libs, I think the above proposed scheme should still be sufficient?</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
c) Kaleb mentioned about removing geo-replication objects from<br>
'glusterfs' and having them in 'glusterfs-geo-replication' only. I<br>
think that might help unless we are breaking something in<br>
geo-replication by doing so. Do we remember the original intent<br>
behind packaging geo-replication objects in the 'glusterfs' package?<br>
<br>
<br>
Which are the geo-replication objects in 'glusterfs'? I don't recall any<br>
incident where something from geo-replication package was moved into<br>
glusterfs package for a specific reason.<br>
</blockquote>
<br></div>
'glusterfs' package has all of the .pyc, .py, .pyo objects that geo-replication needs in addition to gsyncd itself. See attached file for details.</blockquote><div><br></div><div>Hmm, can't think of a reason why all this shouldn't be in glusterfs-geo-replication.rpm.</div>
<div><br></div><div>Avati </div></div></div></div>