On Wed, Aug 14, 2013 at 1:40 AM, Deepak C Shetty < deepa...@linux.vnet.ibm.com> wrote:
> On 08/14/2013 01:37 PM, Anand Avati wrote: > > > > > On Wed, Aug 14, 2013 at 12:25 AM, Deepak C Shetty < > deepa...@linux.vnet.ibm.com> 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>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 >> >> 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. >> > > 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. Avati
_______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel