Bug 1103849 - gear deletion should delete quota entries
Summary: gear deletion should delete quota entries
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OpenShift Online
Classification: Red Hat
Component: Containers
Version: 2.x
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 2.x
Assignee: Rajat Chopra
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks: 1108910
TreeView+ depends on / blocked
 
Reported: 2014-06-02 17:59 UTC by Andy Grimm
Modified: 2016-11-08 03:47 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1108910 (view as bug list)
Environment:
Last Closed: 2014-07-15 10:30:07 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Andy Grimm 2014-06-02 17:59:11 UTC
Description of problem:

I noticed that over time, our quota files have accumulated a large number of entries for deleted users.  At first I thought this only happened when a gear delete failed partway through, but it looks like there's not even an attempt to unset the quota on delete.

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

rubygem-openshift-origin-node-1.24.9-1.el6oso.noarch

How reproducible:

Always

Steps to Reproduce:
1. create an app:

rhc app create test php

2. log into the node, and note the numeric uid of the user

rhc ssh test
id -u

3. delete the app

rhc app delete test

4. Log into the node as root, and run:

repquota -v /var/lib/openshift | grep <UUID>

where <UUID> is the result of the "id -u" command above.

5.  See a line like:

#1567     --       0       0 1048576              0     0 80000       

Actual results:

A quota entry exists

Expected results:

Quota entries should be cleaned up when accounts are deleted.

Additional info:

This should simply be a matter of running this:

"setquota -u <UUID> 0 0 0 0 /var/lib/openshift"

immediately before the user is deleted.  After the fact, you can run the command with the UID instead of UUID.

Comment 1 Jhon Honce 2014-06-02 18:20:38 UTC
The disable_fs_limits() call in selinux_container#destroy() should resolve to the setquota command given in description.

Comment 2 Andy Grimm 2014-06-02 18:53:16 UTC
right, should, but doesn't because you've already deleted the user entry, so you have to set quota for the numeric uid rather than the UUID.  So probably the fix is just changing this in disable_fs_limits:

::OpenShift::Runtime::Node.remove_pam_limits(@container.uuid)

to

::OpenShift::Runtime::Node.remove_pam_limits(@container.uid)

Comment 3 Andy Grimm 2014-06-02 19:34:13 UTC
Comment #2 was obviously a copy-paste fail ... I meant:

::OpenShift::Runtime::Node.remove_quota(@container.uuid)

to

::OpenShift::Runtime::Node.remove_quota(@container.uid)

Comment 4 Meng Bo 2014-06-03 11:25:06 UTC
I can reproduce the bug on devenv-stage_861 with new mount point /.


# repquota -v /
...
#1000     --       0       0 1048576              0     0 80000

Comment 5 Andy Grimm 2014-06-03 15:16:24 UTC
The fix actually takes a little more work due to our use of "always-resolve".  Here's the patch that worked for me:

https://github.com/a13m/origin-server/commit/b7a83174d85d2534b8c4223d04b1b198469e5b6e

I have not gone through the tests yet, though.

Comment 6 Rajat Chopra 2014-06-12 19:56:48 UTC
Fixed with pull request : https://github.com/openshift/origin-server/pull/5503

Comment 7 Meng Bo 2014-06-13 03:12:46 UTC
Checked on devenv_4862, the quota for the deleted gear will be deleted together.

Will also do regression testing for the changes.

Move the bug to verified.


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