On 07/29/2013 12:18 AM, Anand Avati wrote:
On Sun, Jul 28, 2013 at 11:18 AM, Vijay Bellur <vbellur@xxxxxxxxxx
<mailto:vbellur@xxxxxxxxxx>> 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
<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>
With this model, glusterfsd is part of both -server and -fuse. I don't
like this idea entirely, for a different scheme see below.
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.
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. 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.
c) Kaleb mentioned about removing geo-replication objects from
'glusterfs' and having them in 'glusterfs-geo-replication' only. I
think that might help unless we are breaking something in
geo-replication by doing so. Do we remember the original intent
behind packaging geo-replication objects in the 'glusterfs' package?
Which are the geo-replication objects in 'glusterfs'? I don't recall any
incident where something from geo-replication package was moved into
glusterfs package for a specific reason.
'glusterfs' package has all of the .pyc, .py, .pyo objects that
geo-replication needs in addition to gsyncd itself. See attached file
for details.
-Vijay
d) Remove mac-compat.so, rot-13.so, symlink-cache.so from
'glusterfs'. As practically nobody uses these translators today, I
don't see much value in packaging them.
+1
Avati
pm -qlp glusterfs-3.4.0-3.el6.x86_64.rpm | grep sync
warning: glusterfs-3.4.0-3.el6.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID 89ccae8b: NOKEY
/usr/libexec/glusterfs/gsyncd
/usr/libexec/glusterfs/python/syncdaemon
/usr/libexec/glusterfs/python/syncdaemon/README.md
/usr/libexec/glusterfs/python/syncdaemon/__init__.py
/usr/libexec/glusterfs/python/syncdaemon/__init__.pyc
/usr/libexec/glusterfs/python/syncdaemon/__init__.pyo
/usr/libexec/glusterfs/python/syncdaemon/configinterface.py
/usr/libexec/glusterfs/python/syncdaemon/configinterface.pyc
/usr/libexec/glusterfs/python/syncdaemon/configinterface.pyo
/usr/libexec/glusterfs/python/syncdaemon/gconf.py
/usr/libexec/glusterfs/python/syncdaemon/gconf.pyc
/usr/libexec/glusterfs/python/syncdaemon/gconf.pyo
/usr/libexec/glusterfs/python/syncdaemon/gsyncd.py
/usr/libexec/glusterfs/python/syncdaemon/gsyncd.pyc
/usr/libexec/glusterfs/python/syncdaemon/gsyncd.pyo
/usr/libexec/glusterfs/python/syncdaemon/ipaddr.py
/usr/libexec/glusterfs/python/syncdaemon/ipaddr.pyc
/usr/libexec/glusterfs/python/syncdaemon/ipaddr.pyo
/usr/libexec/glusterfs/python/syncdaemon/libcxattr.py
/usr/libexec/glusterfs/python/syncdaemon/libcxattr.pyc
/usr/libexec/glusterfs/python/syncdaemon/libcxattr.pyo
/usr/libexec/glusterfs/python/syncdaemon/master.py
/usr/libexec/glusterfs/python/syncdaemon/master.pyc
/usr/libexec/glusterfs/python/syncdaemon/master.pyo
/usr/libexec/glusterfs/python/syncdaemon/monitor.py
/usr/libexec/glusterfs/python/syncdaemon/monitor.pyc
/usr/libexec/glusterfs/python/syncdaemon/monitor.pyo
/usr/libexec/glusterfs/python/syncdaemon/repce.py
/usr/libexec/glusterfs/python/syncdaemon/repce.pyc
/usr/libexec/glusterfs/python/syncdaemon/repce.pyo
/usr/libexec/glusterfs/python/syncdaemon/resource.py
/usr/libexec/glusterfs/python/syncdaemon/resource.pyc
/usr/libexec/glusterfs/python/syncdaemon/resource.pyo
/usr/libexec/glusterfs/python/syncdaemon/syncdutils.py
/usr/libexec/glusterfs/python/syncdaemon/syncdutils.pyc
/usr/libexec/glusterfs/python/syncdaemon/syncdutils.pyo
