-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow templateinstance controller to instantiate non-v1 objects #14799
Conversation
|
@deads2k @soltysh please can you take a look at this? It seems to solve the issue raised, but:
I think a helper function like https://github.com/openshift/origin/blob/master/pkg/cmd/util/clientcmd/factory.go#L105 would be nice, but I don't know how to create all the clientcmd scaffolding in the contexts above (or better, how to avoid creating all the clientcmd scaffolding). Please can you accept or suggest an acceptable achievable refactor? |
I'm fine with this copy&paste for now. We'll probably want to address that in 3.7, properly. The only missing thing here is a test-case proving that different k8s resources can be easily created. @deads2k agreed? |
@@ -307,10 +311,35 @@ func (c *TemplateInstanceController) instantiate(templateInstance *templateapi.T | |||
RESTMapper: client.DefaultMultiRESTMapper(), | |||
ObjectTyper: kapi.Scheme, | |||
ClientMapper: resource.ClientMapperFunc(func(mapping *meta.RESTMapping) (resource.RESTClient, error) { | |||
config := *c.config | |||
|
|||
// TODO copied from pkg/cmd/util/clientcmd/factory_object_mapping.go#ClientForMapping |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why can't you move this to an openshift /resource
package that returns a clientmapperfunc based on a config?
Suggestion made. I think that centralizing the problem and creating a clientmapperfunc from a config would be sufficient to move us forward. |
updated. [test][testextended][extended:core(templates)] |
removed the merge tag, this appears to have panicked our extended tests: haven't looked into it to confirm it is the culprit. |
oops, too many threads in parallel - fixed and repushed |
|
fixed and repushed |
Evaluated for origin testextended up to 2aabf5d |
Evaluated for origin test up to 2aabf5d |
continuous-integration/openshift-jenkins/testextended SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin_extended/711/) (Base Commit: c3c286b) (PR Branch Commit: 2aabf5d) (Extended Tests: core(templates)) |
continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin/2544/) (Base Commit: c3c286b) (PR Branch Commit: 2aabf5d) |
LGTM |
[merge][severity:blocker] |
Evaluated for origin merge up to 2aabf5d |
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_request_origin/1115/) (Base Commit: 9b2743f) (PR Branch Commit: 2aabf5d) (Extended Tests: blocker) (Image: devenv-rhel7_6396) |
fixes #14780