[Gluster-devel] RPM re-structuring
Deepak C Shetty
deepakcs at linux.vnet.ibm.com
Wed Aug 14 09:00:43 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.
I think the initial reporters didn't understand this completely. My
assumption is that they thought that qemu has dep on libgfapi only.. but
qemu with just libgfapi won't be of any use at all.. except that it
allows qemu to execute w/o cribbing abt libgfapi.so not found error.
As you said before to make qemu w/ libgfapi *useful* one needs to
install glusterfs rpm, and once you do that.. the initial problem
resurfaces when someone removes glusterfs at a later point in time.
Hence i feel if we can ever resolve this dep. issue.
thanx,
deepak
>
> Avati
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130814/bc9c93fe/attachment-0001.html>
More information about the Gluster-devel
mailing list