Add create helpers for users, identities, and mappings from the CLI#8715
Add create helpers for users, identities, and mappings from the CLI#8715openshift-bot merged 1 commit intoopenshift:masterfrom liggitt:create-user
Conversation
|
[test] |
| ==== | ||
|
|
||
|
|
||
| == oc create useridentitymapping |
There was a problem hiding this comment.
I am not sure if this is the best way to expose this feature to users. Are we expecting users to create identities and not map them? When are users creating identities and not using identity providers? I'm not against having these commands in the CLI as I'm sure there are a lot of complex use cases that they enable, but I wonder if we need something different for Joe User.
There was a problem hiding this comment.
Are we expecting users to create identities and not map them? When are users creating identities and not using identity providers?
I would expect them to use these in a script to provision a user one piece at a time, in conjunction with a cluster configured with the "lookup" mappingMethod
I wonder if we need something different for Joe User.
These are not for Joe User... only a cluster admin would have the ability to even run these. As you point out, most of the time, users/identities will get auto-created on login. A cluster admin that needs these is already in advanced territory, so I'd rather just give them the primitives to build exactly what they need.
There was a problem hiding this comment.
Understood. Let's be clear in the help text about when/why you'd use these tools. Otherwise code LGTM. Lots of boilerplate for create, but I'm not really sure if we want or need a better abstraction.
|
LGTM |
pkg/cmd/cli/cmd/create/user.go
Outdated
| UserRecommendedName = "user" | ||
|
|
||
| userLong = ` | ||
| Create a user.` |
There was a problem hiding this comment.
Expound on the help to indicate when I'd want to do use this (and the other) commands. This is only likely to be used if my master-config is set to avoid any auto-provisioning, right? We don't want people thinking they should do this.
|
[merge] |
|
Evaluated for origin test up to 2ab359c |
|
continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/3553/) |
|
since you're retagging anyway, how about a test to make sure this always creates a valid object in |
|
are the created objects in test/cmd/admin.sh not sufficient? |
Didn't notice them. |
|
@mfojtik @bparees
https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/5796/
failed due to something build related
|
|
Standard error from the command: error: no match for Looks like a registry flake to me. |
|
Can you prove it in the openshift logs? We haven't had a flake recently, I On Tue, May 3, 2016 at 9:03 PM, Ben Parees notifications@github.com wrote:
|
|
not sure if this is related:
|
|
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/5801/) (Image: devenv-rhel7_4092) |
|
Evaluated for origin merge up to 2ab359c |
|
what @liggitt found seems likely to be the cause. My only question would be when that error occurs, what is returned to new-app? If new-app gets "invalid", "notfound", or "unauthorized" then it gives up. If it got any other error, it should have fallen back to querying the docker registry directly. i'm guessing that error message resulted in a "not found" or "unauthorized" response, but maybe it shouldn't have. |
|
confirmed in the code, importer.go is going to return that as a NotFound based on the Manifest Unknown error code it received. I'm still not clear on why importer.go got the error it did, but that's why new-app ultimately failed. |
|
Ok, maybe we chalk this up to "a push happened at the same time" or "the On May 3, 2016, at 11:12 PM, Ben Parees notifications@github.com wrote: confirmed in the code, importer.go is going to return that as a NotFound — |
Adds creation helpers for User, Identity, and UserIdentityMapping API objects. Lets you do:
This allows scripting user provisioning for use with the "lookup" mappingMethod.
Note that the identity provider name and identity provider username must exactly match what is determined from the IDP at login time.