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
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.
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.
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!
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
Raising needinfo on Niels for comment9
(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.
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
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