Bug 1564089 - RFE: give user an option to configure OOM kill of gluster processes from memory control scripts(cgroup tunables)
Summary: RFE: give user an option to configure OOM kill of gluster processes from memo...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: core
Version: rhgs-3.4
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
: ---
Assignee: Vijay Bellur
QA Contact: Rahul Hinduja
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-05 10:39 UTC by Nag Pavan Chilakam
Modified: 2018-12-03 09:01 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-12-03 09:01:32 UTC
Embargoed:


Attachments (Terms of Use)

Description Nag Pavan Chilakam 2018-04-05 10:39:41 UTC
Description of problem:
-------------------------
when we set a memory limit for gluster processes through cgroup tunable scripts, as introduced in BZ#1484446, we don't OOM kill the gluster process when the memory  limit is hit.
While we don't want to default to OOM kill, however user must be given an option to configure this.

refer the validation comment in https://bugzilla.redhat.com/show_bug.cgi?id=1484446#c9


Version-Release number of selected component (if applicable):
------
3.12.2-6

Steps to Reproduce:
1.set memory limit through cgroup tunable using gluster script ./control-mem.sh


Expected results:
-------------------
user must be prompted to know if OOM kill should happen when memory limit is hit

Comment 2 Nag Pavan Chilakam 2018-04-05 10:41:27 UTC
However if we are implementing this, we must make sure we are NOT making it default.
Also, we must through a warning if a user is trying to set this

Comment 4 Amar Tumballi 2018-10-24 09:38:23 UTC
Not working on this in near term. If QE is OK, we can close it as DEFERRED and work on it later point in time.

Comment 5 Nag Pavan Chilakam 2018-12-03 08:46:23 UTC
(In reply to Amar Tumballi from comment #4)
> Not working on this in near term. If QE is OK, we can close it as DEFERRED
> and work on it later point in time.

I am ok with closing this bug as deferred or won't fix


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