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
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.
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.
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)
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?
Putting a User's hat.. i think its
a problem.
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 ?
Expecting user (who may or may not be
glsuter/virt. aware) to install addnl
rpm to use qemu gluster might not work
always.
Who will inform user to install
glusterfs when things fail at runtime ?
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.
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 :)
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)?
