[Gluster-devel] RPM re-structuring
Deepak C Shetty
deepakcs at linux.vnet.ibm.com
Wed Aug 14 09:16:09 UTC 2013
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 :)
thanx,
deepak
> Avati
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130814/42b0f0cc/attachment-0001.html>
More information about the Gluster-devel
mailing list