Bug 1025747 - Default district varies between console and rhc when creating apps
Summary: Default district varies between console and rhc when creating apps
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Documentation
Version: 1.2.1
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
: ---
Assignee: Julie
QA Contact: Alex Dellapenta
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-01 12:49 UTC by Andrew Butcher
Modified: 2015-07-20 00:21 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-24 01:49:58 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Andrew Butcher 2013-11-01 12:49:04 UTC
Description of problem:
Creating an application using the broker console will pre-fill options for application gear size from users' available gear sizes. Creating an app using rhc will use broker.conf DEFAULT_GEAR_SIZE, choosing DEFAULT_GEAR_SIZE even if it's not in user's available gear sizes.

Version-Release number of selected component (if applicable):
OSE 1.2.1
rubygem-rhc-1.12.4-1.fc19.noarch


How reproducible:
Always

Steps to Reproduce:
1. Set user available gear sizes to 'int_gen_2, int_gen_3'
2. Set broker.conf DEFAULT_GEAR_SIZE to 'int_gen_1'
3. Create an application using rhc with no gear size specified.

Actual results:
Application will be created in district 'int_gen_1'.

Expected results:
Application would be created in first available district specified for user.

Additional info:
None

Comment 2 Brenton Leanhardt 2014-03-21 19:12:19 UTC
I suspect this is a WONTFIX.  I definitely agree this is surprising to admins.  I just tried against the latest codebase and I see the same behavior.  It's even documented for the most part:

https://access.redhat.com/site/documentation/en-US/OpenShift_Enterprise/2/html-single/Administration_Guide/#Setting_Default_Gear_Quotas_and_Sizes

I think we chould add a note to that section of the docs along the lines of:

Note: While DEFAULT_GEAR_SIZE is not technically required to be in the set of VALID_GEAR_SIZES best practice indicates that it should be.

I'm passing this to docs to let them have their opinion. :)

Comment 5 Luke Meyer 2014-05-29 12:36:13 UTC
+1

The interplay of options here is more confusing than it should be, but at least we have something to point to.

Comment 6 Miciah Dashiel Butler Masters 2014-05-29 14:29:58 UTC
It seems that there are two issues here:

• The user's gear capabilities are exactly those that are derived from DEFAULT_GEAR_CAPABILITIES or set for that user (explicit and obvious enough) as well as whatever the value of DEFAULT_GEAR_SIZE is (implicit and less obvious).  The resolution is to document this behaviour (the clearest change IMO would be to add one sentence to this effect to the existing documentation).

• The management console prevents the user from creating gears with the type specified by DEFAULT_GEAR_SIZE unless it is also in the user's explicit gear capabilities.  Is that correct? Is that behaviour problematic, or should we WONTFIX it?

Comment 7 Julie 2014-06-04 06:12:18 UTC
(In reply to Miciah Dashiel Butler Masters from comment #6)
> It seems that there are two issues here:
> 
> • The user's gear capabilities are exactly those that are derived from
> DEFAULT_GEAR_CAPABILITIES or set for that user (explicit and obvious enough)
> as well as whatever the value of DEFAULT_GEAR_SIZE is (implicit and less
> obvious).  The resolution is to document this behaviour (the clearest change
> IMO would be to add one sentence to this effect to the existing
> documentation).
> 
> • The management console prevents the user from creating gears with the type
> specified by DEFAULT_GEAR_SIZE unless it is also in the user's explicit gear
> capabilities.  Is that correct? Is that behaviour problematic, or should we
> WONTFIX it?
Luke & Miciah,
My understanding is that the bug was originally filed against users being able to create a gear size that is not listed in VALID_GEAR_SIZES but specified in the DEFAULT_GEAR_SIZE parameter, which doesn't make sense in logic. If a size is not available, how can it be set as default.

But since you said what is available to users is really still decided by DEFAULT_GEAR_CAPABILITIES and DEFAULT_GEAR_SIZE (and not VALID_GEAR_SIZES).
I'm a bit confused what VALID_GEAR_SIZES does? In the config file, it says "VALID_GEAR_SIZES: Comma-separated list of valid gear sizes available anywhere in the installation". I'm not sure what that means, so it's for OSE installation and not available gear sizes to users?
 
But then in the guide, it also says "if the <parameter>DEFAULT_GEAR_CAPABILITIES</parameter> value is not set, the <parameter>DEFAULT_GEAR_SIZE</parameter> value determines the gear size new users are allowed to use without an administrator granting access to other sizes." so only one of them have to be set or just setting the DEFAULT_GEAR_SIZE is minimum configuration that has to be done?

Luke,
added a table and hope this makes what needs to be set clearer, but the para still needs to be fixed. Questions in my comment above. 



Many thanks,
Julie

Comment 8 Jason DeTiberus 2014-06-04 14:22:28 UTC
VALID_GEAR_SIZES is the list of all possible gear sizes in the OpenShift deployment.  In order to create a district with a new gear profile, it must first be added to VALID_GEAR_SIZES, otherwise the operation will fail.

Not all users will have the same capabilities (DEFAULT_GEAR_CAPABILITIES sets the default for new users, but each user can be modified after creation).  So, you can have a gear profile that you only add to specific users.  That gear profile would need to be in VALID_GEAR_SIZES, but not DEFAULT_GEAR_CAPABILITIES.

I would suggest that we tell the user to set both DEFAULT_GEAR_CAPABILITIES and DEFAULT_GEAR_SIZE to remove any confusion (and I would suspect most production installations would have more than one gear size anyway).

Comment 10 Luke Meyer 2014-06-04 20:08:53 UTC
+1


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