[Gluster-devel] RPM re-structuring
Deepak C Shetty
deepakcs at linux.vnet.ibm.com
Wed Aug 14 08:40:49 UTC 2013
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 ?
I am thinking if we can ever resolve this issue at all ?
I re-ignited this thread, just to let everyone know that original
problem isn't resolved yet!
thanx,
deepak
(re-sending this as before i mistakenly replied to avati only)
>
> Avati
>
> So today ...
> yum install glusterfs-api brings in glusterfs-libs and glusterfs
> which sounds correct to get a working system with qemu gluster
> backend.
>
> Later...
> yum remove glusterfs
> removes glusterfs-api which has a reverse dep on qemu, hence
> libvirt hence the entire virt stack goes down
>
> which was the original problem reported in the fedora devel list @
> https://lists.fedoraproject.org/pipermail/devel/2013-July/186484.html
>
> and that unfortunately is still there, even after -libs was
> created as a separate rpm as part of this effort!
>
> thanx,
> deepak
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org <mailto:Gluster-devel at nongnu.org>
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130814/7148ccc1/attachment-0001.html>
More information about the Gluster-devel
mailing list