[Gluster-devel] RPM re-structuring

[Anand Avati]

On Wed, Aug 14, 2013 at 1:40 AM, Deepak C Shetty <
deepakcs at 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 <
> deepakcs at 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 <vbellur at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130814/ff1488ca/attachment-0001.html>