Bug 1292321

Summary: Group and user binding relationship is not clear by "describe" or "get" even though group role is shared with user
Product: OpenShift Container Platform Reporter: XiaochuanWang <xiaocwan>
Component: apiserver-authAssignee: David Eads <deads>
Status: CLOSED WONTFIX QA Contact: Wei Sun <wsun>
Severity: low Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: aos-bugs, ccoleman, mmccomas, nagrawal, wsun, xiaocwan
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-04-02 15:37:03 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:
Embargoed:

Description XiaochuanWang 2015-12-17 03:25:30 UTC 
Description of problem:
After "oadm groups add-users", group can't be described for the added user, also missing from "edit user"
After "edit group" to add user, group can't be described for the added user, also missing from "edit user"
After "edit user" to add group, user can't be described for the added group, also missing from "edit group"

Version-Release number of selected component (if applicable):
oadm v1.1-477-g0d4de0b
oc v1.1-477-g0d4de0b
kubernetes v1.1.0-origin-1107-g4c8e6f4

How reproducible:
Always

Steps to Reproduce:
1. After "oadm groups add-users", group can't be described for the added user, also missing from "edit user"
1) oadm groups new group1
2) oadm groups add-users group1 user1
3) oc describe/edit user user1

2. After "edit group" to add user, group can't be described for the added user, also missing from "edit user"
1）oadm groups new group2
2）oc edit group group2 (append "- user2" to "users:")
3）oc describe/edit user user2

3. After "edit user" to add group, user can't be described for the added group, also missing from "edit group"
1) oadm groups new group3
2) oc edit user user3 (append "- group3" to "groups:")
3) oc describe/edit group group3

Actual results:
1.3) user1 doesn't have group1 described, also missing from "edit user"
groups: null
2.3) user2 doesn't have group2 described, also missing from "edit user"
groups: null
3.3) group3 doesn't have user3 described, also missing from "edit group"
users: null


Expected results:
1.3) user1 should have group1 described
2.3) user2 should have group2 described
3.3) group3 should have user3 described

Additional info:
1.3) Role for group1 can share with user1
2.3) Role for group2 can share with user2
Comment 1 David Eads 2015-12-17 21:01:08 UTC 
The `Groups` field on a `User` is not virtualized.  They are two different ways of representing the group, that means that `edit` on the resources can't behave the way you've described.

I don't think we have non-congruent groups between update and get, so I probably wouldn't change the get behavior to collapse them either.

I see a couple options:
 1. Sub-resource on a user to get its groups.  This seems pretty reasonable.
 1. Status.Groups on a User that indicates its current group affiliations as known by the server.

I think both are reasonable.

Jordan, Clayton opinions?
Comment 2 Jordan Liggitt 2015-12-21 14:35:27 UTC 
Agree... `groups` field on user != all group memberships. Need to document that (and maybe mark groups field as deprecated?).

I think I'd lean toward the subresource to keep the user call cheap and small, but I need to think about that a little more
Comment 3 David Eads 2015-12-21 14:46:22 UTC 
The API is functioning as expected.  Its a little difficult to follow as a user, but no data is being lost and the rolebindings are operating as expected.

XiaochuanWang: If you agree, can you reduce severity to "low"?
Comment 4 XiaochuanWang 2015-12-23 06:16:29 UTC 
severity is down to "low"