| Summary: | "glusterfs-events" package installation is happening when gluster processes are running. | ||
|---|---|---|---|
| Product: | Red Hat Gluster Storage | Reporter: | Byreddy <bsrirama> |
| Component: | build | Assignee: | Milind Changire <mchangir> |
| Status: | CLOSED WORKSFORME | QA Contact: | Rahul Hinduja <rhinduja> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rhgs-3.2 | CC: | amukherj, bsrirama, rhs-bugs, storage-qa-internal |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-10-18 09:14:29 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Byreddy
2016-10-04 06:52:49 UTC
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. |