gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] RPM re-structuring


From: Vijay Bellur
Subject: Re: [Gluster-devel] RPM re-structuring
Date: Mon, 29 Jul 2013 00:43:01 +0530
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6

On 07/29/2013 12:37 AM, Anand Avati wrote:



On Sun, Jul 28, 2013 at 12:02 PM, Vijay Bellur <address@hidden
<mailto:address@hidden>> wrote:

    On 07/29/2013 12:18 AM, Anand Avati wrote:




        On Sun, Jul 28, 2013 at 11:18 AM, Vijay Bellur
        <address@hidden <mailto:address@hidden>
        <mailto:address@hidden <mailto:address@hidden>>> 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
        <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>
        <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.


How? libgfapi depends only on glusterfs-libs. Whereas glusterfsd is in
glusterfs rpm.

In the scenario when somebody tries to use the gluster client xlators via libgfapi, we would end up installing glusterfsd still. Do we really need that to happen?

-Vijay



reply via email to

[Prev in Thread] Current Thread [Next in Thread]