[Gluster-devel] RPM re-structuring
Deepak C Shetty
deepakcs at linux.vnet.ibm.com
Wed Aug 14 09:45:31 UTC 2013
On 08/14/2013 02:57 PM, Anand Avati wrote:
>
> On Wed, Aug 14, 2013 at 2:16 AM, Deepak C Shetty
> <deepakcs at linux.vnet.ibm.com <mailto:deepakcs at linux.vnet.ibm.com>> wrote:
>
> On 08/14/2013 02:23 PM, Anand Avati wrote:
>>
>>
>>
>> On Wed, Aug 14, 2013 at 1:40 AM, Deepak C Shetty
>> <deepakcs at linux.vnet.ibm.com
>> <mailto: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
>>> <mailto: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 <mailto: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
>>>> <http://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.
>>
>
> 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)?
I agree.
>
> Avati
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130814/ff1234a3/attachment-0001.html>
More information about the Gluster-devel
mailing list