On 08/14/2013 12:55 PM, Deepak C Shetty wrote:
On 07/29/2013 12:18 AM, Anand Avati wrote:
On Sun, Jul 28, 2013 at 11:18 AM, Vijay Bellur <vbel...@redhat.com
<mailto:vbel...@redhat.com>> wrote:
Hi All,
There was a recent thread on fedora-devel about bloated glusterfs
dependency for qemu:
https://lists.fedoraproject.org/pipermail/devel/2013-July/186484.html
As of today, we have the following packages and respective
primary constituents:
1. glusterfs - contains all the common xlators,
libglusterfs, glusterfsd binary & glusterfs symlink to glusterfsd.
2. glusterfs-rdma - rdma shared library
3. glusterfs-geo-replication - geo-rep related objects
4. glusterfs-fuse - fuse xlator
5. glusterfs-server - server side xlators, config files
6. glusterfs-api - libgfapi shared library
7. glusterfs-resource-agents - OCF resource agents
8. glusterfs-devel - Header files for libglusterfs
9. glusterfs-api-devel - Header files for gfapi
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:
a) Move glusterfsd and glusterfs symlink from 'glusterfs' to
'glusterfs-server'
b) Package glusterfsd binary and glusterfs symlink in
'glusterfs-fuse'
Does that mean glusterfsd is in glusterfs-server or glusterfs-fuse?
It is probably sufficient to leave glusterfs-fuse just have fuse.so
and mount.glusterfs.in <http://mount.glusterfs.in>
Another model can be:
0. glusterfs-libs.rpm - libglusterfs.so libgfrpc.so libgfxdr.so
1. glusterfs (depends on glusterfs-libs) - glusterfsd binary,
glusterfs symlink, all common xlators
2. glusterfs-rdma (depends on glusterfs) - rdma shared library
3. glusterfs-geo-replication (depends on glusterfs) - geo-rep related
objects
4. glusterfs-fuse (depends on glusterfs) - fuse xlator, mount.glusterfs
5. glusterfs-server (depends on glusterfs) - server side xlators,
config files
6. glusterfs-api (depends on glusterfs-libs) - libgfapi.so and api.so
7. glusterfs-resource-agents (depends on glusterfs)
8. glusterfs-devel (depends on glusterfs-libs) - header files for
libglusterfs
9. glusterfs-api-devel (depends on glusterfs-api) - header files for
gfapi
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.
Looks like even after the re-packaging.. the original problem is still
there !
Post re-strucuring ( i am on F19 with updates-testing repo enabled)
gluserfs-api has dep on -libs and glusterfs
So when User install glusterfs-api, it pulls in -libs and glusterfs
This is correct, since w/o glusterfs rpm we won't have a working qemu
gluster backend. 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)
So today ...
yum install glusterfs-api brings in glusterfs-libs and glusterfs
which sounds correct to get a working system with qemu gluster backend.
Later...
yum remove glusterfs
removes glusterfs-api which has a reverse dep on qemu, hence libvirt
hence the entire virt stack goes down
See http://paste.fedoraproject.org/31972/64604451/
which was recorded on a F19 system
which was the original problem reported in the fedora devel list @
https://lists.fedoraproject.org/pipermail/devel/2013-July/186484.html
and that unfortunately is still there, even after -libs was created as
a separate rpm as part of this effort!
thanx,
deepak
_______________________________________________
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel
