Hide Forgot
Description of problem: ======================= "glusterfs-events" package installation is happening when gluster processes are running. glusterfs_build2]# yum install glusterfs-events-3.8.4-2.el7rhgs.x86_64.rpm Loaded plugins: langpacks, product-id, rhnplugin, search-disabled-repos, subscription-manager This system is receiving updates from RHN Classic or Red Hat Satellite. Examining glusterfs-events-3.8.4-2.el7rhgs.x86_64.rpm: glusterfs-events-3.8.4-2.el7rhgs.x86_64 Marking glusterfs-events-3.8.4-2.el7rhgs.x86_64.rpm to be installed Resolving Dependencies --> Running transaction check ---> Package glusterfs-events.x86_64 0:3.8.4-2.el7rhgs will be installed --> Finished Dependency Resolution Dependencies Resolved ============================================================================================================================================================================================== Package Arch Version Repository Size ============================================================================================================================================================================================== Installing: glusterfs-events x86_64 3.8.4-2.el7rhgs /glusterfs-events-3.8.4-2.el7rhgs.x86_64 82 k Transaction Summary ============================================================================================================================================================================================== Install 1 Package Total size: 82 k Installed size: 82 k Is this ok [y/d/N]: y Downloading packages: Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : glusterfs-events-3.8.4-2.el7rhgs.x86_64 1/1 Verifying : glusterfs-events-3.8.4-2.el7rhgs.x86_64 1/1 Installed: glusterfs-events.x86_64 0:3.8.4-2.el7rhgs Complete! [root@glusterfs_build2]# ~]# rpm -qa |grep glusterfs-events glusterfs-events-3.8.4-2.el7rhgs.x86_64 Version-Release number of selected component (if applicable): ============================================================= glusterfs-3.8.4-2 How reproducible: ================== Always Steps to Reproduce: ==================== 1.Have glusterfs processes running setup 2.Install the glusterfs-events package Actual results: =============== "glusterfs-events" package installation is happening when gluster processes are running. Expected results: ================= Package installation should not happen if gluster processes are running. Additional info:
On what basis do you think that glusterfs-events package shouldn't be allowed to install when there is running glusterfs(d) process instances?
Normally even Operating System packages are updated when the operating system is running. eg. glibc, which is the most wide used shared library is updated when processes are actively using the library. The newer library is loaded when the process is restarted, and until then the processes already running continue to use the older library. Admins are advised to follow standard package updating guidelines, which involves acquiescing the node, i.e. shutting down gluster processes, to update the RPMs. Adding checks to RPMs is not the solution.
(In reply to Milind Changire from comment #3) > Normally even Operating System packages are updated when the operating > system is running. eg. glibc, which is the most wide used shared library is > updated when processes are actively using the library. The newer library is > loaded when the process is restarted, and until then the processes already > running continue to use the older library. > > Admins are advised to follow standard package updating guidelines, which > involves acquiescing the node, i.e. shutting down gluster processes, to > update the RPMs. > > Adding checks to RPMs is not the solution. I am not agreeing this is NOT A BUG. This is my explanation: Except this events package, we are not allowing to install any other gluster packages if gluster processes are running we need to follow the same procedure for this gluster events package as well. Moving the bug back to assigned state.
(In reply to Byreddy from comment #4) > (In reply to Milind Changire from comment #3) > > Normally even Operating System packages are updated when the operating > > system is running. eg. glibc, which is the most wide used shared library is > > updated when processes are actively using the library. The newer library is > > loaded when the process is restarted, and until then the processes already > > running continue to use the older library. > > > > Admins are advised to follow standard package updating guidelines, which > > involves acquiescing the node, i.e. shutting down gluster processes, to > > update the RPMs. > > > > Adding checks to RPMs is not the solution. > > > I am not agreeing this is NOT A BUG. > > This is my explanation: > Except this events package, we are not allowing to install any other > gluster packages if gluster processes are running > we need to follow the same procedure for this gluster events package as well. > > Moving the bug back to assigned state. As discussed, the point here is disrupting the running services is an overhead and should be only done if there is an impact on a fresh package installation if we don't bring down the other running instances. For glustereventsd as of now, we don't see any reason of introducing that unnecessary overhead to disrupting the running services. I believe this is the last clarification what you needed and this bug now can be closed. Please ack.
(In reply to Atin Mukherjee from comment #5) > (In reply to Byreddy from comment #4) > > (In reply to Milind Changire from comment #3) > > > Normally even Operating System packages are updated when the operating > > > system is running. eg. glibc, which is the most wide used shared library is > > > updated when processes are actively using the library. The newer library is > > > loaded when the process is restarted, and until then the processes already > > > running continue to use the older library. > > > > > > Admins are advised to follow standard package updating guidelines, which > > > involves acquiescing the node, i.e. shutting down gluster processes, to > > > update the RPMs. > > > > > > Adding checks to RPMs is not the solution. > > > > > > I am not agreeing this is NOT A BUG. > > > > This is my explanation: > > Except this events package, we are not allowing to install any other > > gluster packages if gluster processes are running > > we need to follow the same procedure for this gluster events package as well. > > > > Moving the bug back to assigned state. > > As discussed, the point here is disrupting the running services is an > overhead and should be only done if there is an impact on a fresh package > installation if we don't bring down the other running instances. For > glustereventsd as of now, we don't see any reason of introducing that > unnecessary overhead to disrupting the running services. > > I believe this is the last clarification what you needed and this bug now > can be closed. Please ack. python-gluster is a dependency package for glusterfs-events, python-gluster package will not get installed if gluster processes are running so we have to disrupt the running services to install glusterfs-events package. With out disrupting the existing setup we can't install/update the glusterfs-events package
Closing this bug based on above comment details. We are achieving the required thing with the dependency package.