<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 14, 2013 at 2:16 AM, Deepak C Shetty <span dir="ltr"><<a href="mailto:deepakcs@linux.vnet.ibm.com" target="_blank">deepakcs@linux.vnet.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
<div>On 08/14/2013 02:23 PM, Anand Avati
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Aug 14, 2013 at 1:40 AM,
Deepak C Shetty <span dir="ltr"><<a href="mailto:deepakcs@linux.vnet.ibm.com" target="_blank">deepakcs@linux.vnet.ibm.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<div>On 08/14/2013 01:37 PM, Anand Avati wrote:<br>
</div>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Aug 14, 2013
at 12:25 AM, Deepak C Shetty <span dir="ltr"><<a href="mailto:deepakcs@linux.vnet.ibm.com" target="_blank">deepakcs@linux.vnet.ibm.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<div>
<div>On 07/29/2013 12:18 AM, Anand
Avati wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On
Sun, Jul 28, 2013 at 11:18
AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi
All,<br>
<br>
There was a recent thread
on fedora-devel about
bloated glusterfs
dependency for qemu:<br>
<br>
<a href="https://lists.fedoraproject.org/pipermail/devel/2013-July/186484.html" target="_blank">https://lists.fedoraproject.org/pipermail/devel/2013-July/186484.html</a><br>
<br>
As of today, we have the
following packages and
respective primary
constituents:<br>
<br>
1. glusterfs
- contains all the
common xlators,
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
turn is dependent on
glusterfs. Much of the
apparent bloat is coming
from glusterfs package and
one proposal for reducing
the dependency footprint
of consumers of libgfapi
could be the following:<br>
<br>
a) Move glusterfsd and
glusterfs symlink from
'glusterfs' to
'glusterfs-server'<br>
b) Package glusterfsd
binary and glusterfs
symlink in
'glusterfs-fuse'<br>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>Does that mean
glusterfsd is in
glusterfs-server or
glusterfs-fuse? It is
probably sufficient to
leave glusterfs-fuse just
have fuse.so and <a href="http://mount.glusterfs.in" target="_blank">mount.glusterfs.in</a></div>
<div><br>
</div>
<div>Another model can be:</div>
<div><br>
</div>
<div>0. glusterfs-libs.rpm -
libglusterfs.so
libgfrpc.so libgfxdr.so</div>
<div>1. glusterfs (depends
on glusterfs-libs) -
glusterfsd binary,
glusterfs symlink, all
common xlators</div>
<div>2. glusterfs-rdma
(depends on glusterfs) -
rdma shared library</div>
<div>3.
glusterfs-geo-replication
(depends on glusterfs) -
geo-rep related objects</div>
<div>4. glusterfs-fuse
(depends on glusterfs) -
fuse xlator,
mount.glusterfs</div>
<div>5. glusterfs-server
(depends on glusterfs) -
server side xlators,
config files</div>
<div>6. glusterfs-api
(depends on
glusterfs-libs) -
libgfapi.so and api.so</div>
<div>7.
glusterfs-resource-agents
(depends on glusterfs)</div>
<div>8. glusterfs-devel
(depends on
glusterfs-libs) - header
files for libglusterfs</div>
<div>9. glusterfs-api-devel
(depends on glusterfs-api)
- header files for gfapi</div>
<div><br>
</div>
<div>This way qemu will only
pick up libgfapi.so
libglusterfs.so
libgfrpc.so and
libgfxdr.so (the bare
minimum to "just execute")
for the binary to load at
run time. Those who want
to store vm images
natively on gluster must
also do a 'yum install
glusterfs' to make gfapi
'useful'. This way Fedora
qemu users who do not plan
to use gluster will not
get any of the xlator
cruft.</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</div>
Looks like even after the re-packaging..
the original problem is still there !<br>
Post re-strucuring ( i am on F19 with
updates-testing repo enabled) <br>
<br>
gluserfs-api has dep on -libs and
glusterfs<br>
So when User install glusterfs-api, it
pulls in -libs and glusterfs<br>
<br>
This is correct, since w/o glusterfs rpm
we won't have a working qemu gluster
backend.</div>
</blockquote>
<div><br>
</div>
<div>Actually this *wasnt* what we
discussed. glusterfs-api was supposed to
depend on glusterfs-libs *ONLY*. This is
because it has a linking (hard)
relationship with glusterfs-libs, and
glusterfs.rpm is only a run-time
dependency - everything here is
dlopen()ed.<br>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Just allowing qemu to execute by way of
installing-libs and -api only won't
help, since once qemu executes and
someone tries qemu w/ gluster backend..
things will fail unless User has
installed glusterfs rpm (which has all
the client xlators)<br>
</div>
</blockquote>
<div><br>
</div>
<div>I think this was exactly what we
concluded. That a user would need to
install glusterfs rpm if they wanted to
store VM images on gluster (independent of
the fact that qemu was linked with
glusterfs-api). Do you see a problem with
this?</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</div>
<div> Putting a User's hat.. i think its a
problem.<br>
IIUC What you are saying is that User must be aware
that he/she needs to install glusterfs in order to use
qemu gluster backend. User may argue.. why didn't you
install glusterfs as part of qemu yum install itself ?<br>
<br>
Expecting user (who may or may not be glsuter/virt.
aware) to install addnl rpm to use qemu gluster might
not work always.<br>
<br>
</div>
Who will inform user to install glusterfs when things
fail at runtime ?</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div><span style="font-family:arial,sans-serif;font-size:13px">Your
view is in direct contradiction with the view of those
who objected the dependency to start with :-) I think
this question needs to be reconciled with the initial
reporters.</span><br>
</div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
</div>
</div>
</div>
</blockquote>
<br></div></div>
One more point to note here is that... even if we go with the way
you suggested, it solves the original problem but brings in another
as I stated above. People forgetting to install glusterfs would end
up in qemu runtime error which i feel is even worse. So your re-pkg
doesn't end the problem afaics :) It just moves the problem to a
diff. place at a diff. time :)<br></div></blockquote><div><br></div><div>You're probably right. Also given the fact that the objections died out after Kaleb did the explaining, I'm not sure if we need to do any more changes (and leave the dependency as-is)?</div>
<div><br></div><div>Avati</div></div></div></div>