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
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?
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
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"?
severity is down to "low"