Bug 1122496 - Can't clone application of additional storage within owner domain by admin/edit member which has no additional stroage capability
Summary: Can't clone application of additional storage within owner domain by admin/ed...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Node
Version: 2.1.0
Hardware: Unspecified
OS: Unspecified
high
low
Target Milestone: ---
: ---
Assignee: Brenton Leanhardt
QA Contact: libra bugs
URL:
Whiteboard:
Depends On: 1121971
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-23 11:37 UTC by Brenton Leanhardt
Modified: 2014-08-26 13:52 UTC (History)
11 users (show)

Fixed In Version: openshift-origin-broker-1.16.1.11-1.el6op, rubygem-openshift-origin-controller-1.23.10.8-1.el6op
Doc Type: Bug Fix
Doc Text:
When creating an application, it was possible in certain situations for a user without the additional storage capability to add storage within a domain. This occurred because the additional storage capability was checked for the wrong user account, which was due to a bug in the broker's controller library. This bug fix updates the controller library and now the domain owner's capabilities are correctly checked.
Clone Of: 1121971
Environment:
Last Closed: 2014-08-26 13:52:51 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1095 0 normal SHIPPED_LIVE Red Hat OpenShift Enterprise 2.1.5 bug fix and enhancement update 2014-08-26 17:51:34 UTC

Description Brenton Leanhardt 2014-07-23 11:37:38 UTC
+++ This bug was initially created as a clone of Bug #1121971 +++

Description of problem:
Create an application adding addition storage in domain1 for account1.
Add account2 to account1 with admin/edit role.(account2 has no additional storage capability)
Clone this app within domain1 by account2.Will show "account1 has requested more additional gear storage than allowed (max: 0 GB)"

Could add storage to domain1's app by account2.

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

How reproducible:
always

Steps to Reproduce:
1.Add account2 to account1 as admin/edit member.
rhc member add account2 -r admin -n domain1 

2.Create an application, and add some additional storage.
rhc app create php php-5.3 -n domain1
rhc cartridge-storage php-5.3 -a php --add 10 -n domain1 -l account2

3.Clone this app within domain1 by account2
rhc app create phpc --from-app=domain1/php -n domain1 -l account2

Actual results:
step 3:
]# rhc app create  phpc  --from-app=domain1/php -n domain1 -l account2 
Application Options
-------------------
Domain:     domain1
Cartridges: php-5.3
From app:   php
Gear Size:  Copied from 'php'
Scaling:    no (copied from 'php')

Creating application 'phpc' ... account2 has requested more additional gear storage than allowed (max: 0 GB)

Expected results:
Could clone app of additional storage within owner domain by admin/edit role which has no additional storage capability.

Additional info:

--- Additional comment from Jordan Liggitt on 2014-07-22 09:11:05 EDT ---

applications_controller in the broker is doing two checks during app creation, based on the user doing the creation, rather than the owner of the domain:

    if (@cloud_user.consumed_gears >= @cloud_user.max_gears)
      return render_error(:unprocessable_entity,
                          "#{@cloud_user.login} has already reached the gear limit of #{@cloud_user.max_gears}",
                          104)
    end


    if (cartridges.map(&:additional_gear_storage).compact.map(&:to_i).max || 0) > @cloud_user.max_storage
      return render_error(:unprocessable_entity,
                          "#{@cloud_user.login} has requested more additional gear storage than allowed (max: #{@cloud_user.max_storage} GB)",
                          166)
    end


Both of these checks are incorrect... the gears and extra storage should be validated against the capabilities of the owner of the domain where the app is being created, not the calling user.

--- Additional comment from Jordan Liggitt on 2014-07-22 09:14:34 EDT ---

Simply need to validate against @domain.owner.consumed_gears and @domain.owner.max_storage

--- Additional comment from Jordan Liggitt on 2014-07-22 09:54:58 EDT ---

Will merge fix in https://github.com/openshift/origin-server/pull/5638

--- Additional comment from openshift-github-bot on 2014-07-22 18:08:39 EDT ---

Commit pushed to master at https://github.com/openshift/origin-server

https://github.com/openshift/origin-server/commit/525547875c4673e2a317c013fd6053ed792c4b58
Bug 1121971: Validate based on domain owner capabilities during app create

--- Additional comment from XiuJuan Wang on 2014-07-23 02:12:41 EDT ---

Checked on devenv_4998

Can't reproduce this bug.Will verify this bug after on_qa.

Comment 1 Brenton Leanhardt 2014-08-01 14:20:39 UTC
Upstream commit:

commit 525547875c4673e2a317c013fd6053ed792c4b58
Author: Jordan Liggitt <jliggitt>
Date:   Tue Jul 22 09:16:31 2014 -0400

    Bug 1121971: Validate based on domain owner capabilities during app create

Comment 4 Ma xiaoqiang 2014-08-04 06:01:46 UTC
Check on puddle[2.1.5/2014-08-01.1]

1.Create an app with xiaom
#rhc app create phps php-5.4 -s -l xiaom -n xiaom
2.add user 'xiama' to domain 'xiaom'
#rhc member add xiama -n xiaom -r admin
3.set max tracked storage for xiaom 
#oo-admin-ctl-user -l xiaom  --setmaxtrackedstorage 20
4.add storage for app with xiama 
rhc cartridge storage php --set 10 -a phps -l xiama
5.clone a new app from phps 
#rhc app create phpc --from-app xiaom/phps -l xiama

The app is created successfully! so move the issue to VERIFIED.

Comment 6 errata-xmlrpc 2014-08-26 13:52:51 UTC
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.

http://rhn.redhat.com/errata/RHBA-2014-1095.html


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