Bug 1219793 - Dependency problem due to glusterfs-api depending on glusterfs instead of only glusterfs-libs [rhel-6]
Summary: Dependency problem due to glusterfs-api depending on glusterfs instead of onl...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: core
Version: rhgs-3.1
Hardware: Unspecified
OS: Linux
high
high
Target Milestone: ---
: RHGS 3.1.0
Assignee: Niels de Vos
QA Contact: SATHEESARAN
URL:
Whiteboard:
Depends On: 1075802 1194503 1195947
Blocks: 1194508 1202842
TreeView+ depends on / blocked
 
Reported: 2015-05-08 09:59 UTC by Vivek Agarwal
Modified: 2016-09-17 14:42 UTC (History)
12 users (show)

Fixed In Version: glusterfs-3.7.1-3.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 1194503
Environment:
Last Closed: 2015-07-29 04:42:36 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1353853 0 None None None Never
Red Hat Product Errata RHSA-2015:1495 0 normal SHIPPED_LIVE Important: Red Hat Gluster Storage 3.1 update 2015-07-29 08:26:26 UTC

Comment 5 SATHEESARAN 2015-07-10 17:25:53 UTC
I don't get the expectation of this bug.

I have the following questions,

1. The bug from which this bug is actually cloned is still in NEW state.

2. After reading through the customer cases attached, I see that the glusterfs logrotate file reconfigured the logrotate configuration from 4 to 52weeks
This is still not fixed.

3. Customer doesn't wanted glusterfs in his embedded platform. You can see in comment0, here is the snip - 
<snip>
"This all happens even if the customer has no desire to use the glusterfs capabilities.This is a serious problem for customers, particularly embedded vendor partners, who must use a minimal installation to limit their exposure to bugs and security vulnerabilities."
</snip>
Is this possible to remove QEMU/KVM dependency on glusterfs, in the case the user doesn't uses gluster ?

4. As I read from comment0, I see that customer is looking for lesser number of gluster packages pulled by qemu/kvm, but right now with RHGS 3.1 we have increased the number of dependent packages pulled up by QEMU/KVM

The packages pulled by QEMU/KVM are,
glusterfs-api
glusterfs-libs
glusterfs
glusterfs-client-xlators

Won't that increase the customer's worries ?

Actually package dependency problem for glusterfs-api have been verified as part of bug https://bugzilla.redhat.com/show_bug.cgi?id=1082659

Can we use this bug to resolve the problems as mentioned in my above 4 points ?
If so, we can remove this bug from RHGS 3.1 errata and re-propose it for RHGS 3.1.z

Moving the bug to ASSIGNED state to sort-out above mentioned 4 issues

Comment 6 Terry Bowling 2015-07-10 19:34:02 UTC
Item 2 is address by the following BZ's to fix the logrotate configuration issue.

	RHEL 7:  https://bugzilla.redhat.com/show_bug.cgi?id=1172542
	RHEL 6:  https://bugzilla.redhat.com/show_bug.cgi?id=1171865

	Already fixed in:
	https://bugzilla.redhat.com/show_bug.cgi?id=1099539
	https://bugzilla.redhat.com/show_bug.cgi?id=1126801

This BZ is to address the dependency concern in the RH Storage Product, while it's parent bz1194503 & bz1194508 is the same for the RHEL 6 & 7 Product.  So it's purpose is for the different Business Unit.  I think ;-)

And then there's bz1195947.  Not sure how it fits into the picture.

In summary, customer's request is to minimize their exposure to dependency creep since they are not using glusterfs and feel they should not need any of it.  However it is understood that qemu-kvm needs some minimal components.  But hopefully this can be restructured and minimized.

Comment 7 Niels de Vos 2015-07-10 20:52:10 UTC
The dependencies of the packages have been cleaned, and the contents of the packages has been reduced. When qemu-kvm gets installed, it should not pull in any of the packages that provides executables in $PATH. One of the concerns was that there is a glusterfs and glusterfsd binary installed, these should not be there anymore.

It is correct that qemu-kvm pulls in these packages:

  qemu-kvm
     '- glusterfs-api                   -> provides libgfapi.so
            |- glusterfs-libs           -> basic gluster libraries
            |- glusterfs                -> shared client+server files
            '- glusterfs-client-xlators -> xlators loaded by libgfapi.so

There is very little to nothing that we can strip out more. Other projects need similar flexibility, but have slightly different demands. This caused an increase in the number of packages, but each package has less contents. This is one of the upstream related emails that adds a little more context:

  http://article.gmane.org/gmane.comp.file-systems.gluster.devel/10643


Bug 1195947 is the Gluster Community version for this change. Any modifications we make, we push them "upstream first". For that, we need an upstream bug to describe the problem and be able to track progress.

This is now marked as FaileQA because the number of packages has increased. I do not think there is a decent way to reduce the number of packages, and address different use-cases.

Terry, what would be the acceptance criteria for your customer? Also note that upstream qemu might move to a more friendly way of building/packaging. Recent Fedora bug 1240965 might interest you, you could consider basing an RFE for qemu in RHEL on that.

Comment 8 Terry Bowling 2015-07-10 21:01:57 UTC
Thanks Neils!

The customer did not provide any firm criteria but were strongly opposed to having the client or server daemon binaries installed, as well as config files such as the logrotate one that caused them problems.

I have 2 embedded telco customers and both of them have expressed concern about the growing rpm dependencies in general over the rhel 6 lifecycle.  But they accept some of this comes with the progress and technology advances we are making.

I agree that the RFE for a more modular qemu is what we need in this case.  I will take that action.  If we can assure them that the config files and client/server binaries are excluded, they will be satisfied.

Thanks again everyone!

Comment 9 SATHEESARAN 2015-07-11 05:04:12 UTC
Thanks Terry and Neils for your valuable suggestions/thoughts.

From comment6, comment7, comment8 - I summarize the following :

(1) gluster re-configuring the default logrotate configurations are taken care in a separate bugs. ( comment6 )

(2) The dependencies of the packages have been cleaned, and the contents of the packages has been reduced. When qemu-kvm gets installed, one of the concerns was that there is a glusterfs and glusterfsd binary installed, these should not be there anymore.

There is very little to nothing that we can strip out more.

(3) Terry to take action to raise a RFE for more modular QEMU, which excludes glusterfs dependency while installing QEMU

Neils,

I could verify this bug with point (2) mentioned above -  as the expected result.
If you agree, then you can move this bug back to ON_QA based on above conversations

Comment 10 SATHEESARAN 2015-07-11 05:07:59 UTC
Raising needinfo on Niels for comment9

Comment 11 Niels de Vos 2015-07-11 06:39:15 UTC
(In reply to SATHEESARAN from comment #9)
> I could verify this bug with point (2) mentioned above -  as the expected
> result.
> If you agree, then you can move this bug back to ON_QA based on above
> conversations

Yep, point (2) states my expectation of the main outcome of this bug.

Comment 12 SATHEESARAN 2015-07-12 05:51:40 UTC
Tested with RHGS 3.1 Nightly ( glusterfs-3.7.1-8.el6rhs ), and observed the following :

1. No glusterfs or glusterfsd binaries available under /usr/sbin/

[root@ ~]# which glusterfs
/usr/bin/which: no glusterfs in (/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin)

[root@ ~]# which glusterfsd
/usr/bin/which: no glusterfsd in (/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin)

[root@rhs-client10 ~]# ls /usr/sbin/gluster*
ls: cannot access /usr/sbin/gluster*: No such file or directory

[root@ ~]# ls /usr/bin/gluster*
ls: cannot access /usr/bin/gluster*: No such file or directory

2. Package dependency was cleaned up.

now qemu-kvm installs glusterfs, glusterfs-api, glusterfs-libs, glusterfs-client-xlators package as a dependency

Following is the dependent packages as seen in RHEL 6.7

[root@ ~]# rpm -qa | grep gluster
glusterfs-libs-3.7.1-8.el6.x86_64
glusterfs-client-xlators-3.7.1-8.el6.x86_64
glusterfs-3.7.1-8.el6.x86_64
glusterfs-api-3.7.1-8.el6.x86_64

[root@ ~]# rpm -qR qemu-kvm | grep gluster
glusterfs-api  

[root@ ~]# rpm -qR glusterfs-api | grep gluster
glusterfs = 3.7.1-8.el6
glusterfs-client-xlators = 3.7.1-8.el6
libglusterfs.so.0()(64bit)  

[root@ ~]# rpm -qR glusterfs | grep gluster
glusterfs-libs = 3.7.1-8.el6
libglusterfs.so.0()(64bit)  

[root@ ~]# rpm -qR glusterfs-libs | grep gluster
libglusterfs.so.0()(64bit)  

[root@ ~]# rpm -qR glusterfs-client-xlators | grep gluster
libglusterfs.so.0()(64bit)  

Marking this bug as VERIFIED.
Removing FailedQA flag from this bug, as the earlier FailedQA was incorrect based on conversation in comment6 , comment7, comment8

Comment 13 errata-xmlrpc 2015-07-29 04:42:36 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-1495.html


Note You need to log in before you can comment on or make changes to this bug.