'incorrect namespace' error from create() with objects for other namespaces about jenkins-client-plugin HOT 8 CLOSED

@alanbchristie yep, at face value I would agree.

Ultimately, we are talking about some rework of https://github.com/openshift/jenkins-client-plugin/blob/master/src/main/resources/com/openshift/jenkins/plugins/OpenShiftDSL.groovy#L497-L528
where we possibly need to make more RPCs, and we have a bit of regression testing to perform
since that code path is common to a lot of our oc verb equivalents.

Because of the RPC implications, I'm wondering if we want to introduce and optimization option which would allow the code to assume a common namespace.

As such, I'd like to have some discussion on our (openshif dev) end to get to a consensus on things. But certainly chime in with any thoughts along those lines you have as well @alanbchristie

@openshift/sig-developer-experience fyi / ptal

@jupierce if you have an historical notes on the obj combination logic I referenced above please advise (the same basic form seems to have been in place since the early commits).

thanks

from jenkins-client-plugin.

OK ... I found some related history with openshift/origin#12277 , a bug @bparees and @jupierce worked in late 2016.

And see this snippet from @jupierce for the process command:

    public ArrayList<HashMap> process(Object obj,Object... oargs) throws AbortException {
        String[] args = toStringArray(oargs);

        if (obj instanceof Map) {
            if (obj.kind != "Template") {
                throw new AbortException("Expected Template object, but received: " + obj.toString());
            }
            // https://github.com/openshift/origin/issues/12277
            Map template = new HashMap((Map)obj);
            template.metadata.remove('namespace');
            template.metadata.remove('selfLink');
            obj = JsonOutput.toJson(template);
        }

Now, the openshift/origin process template source from that issue has been reworked quite a since the activity from @bparees and @jupierce in late 2016.

And the comment from the origin docs that @jupierce reference befored is still present, but it has evolved to include the new parameter substitution support:

If an object definition’s metadata includes a fixed namespace field value, the field will be stripped out of the definition during template instantiation. If the namespace field contains a parameter reference, normal parameter substitution will be performed and the object will be created in whatever namespace the parameter substitution resolved the value to, assuming the user has permission to create objects in that namespace.

Still wrapping my head around all this, but I'm wondering if we don't just leave metadata.namespace in the obj (i.e. remove the template.metadata.remove('namespace'); call).

Insights / opinions welcome while I cogitate

from jenkins-client-plugin.

I think I may have it:

1. the code I mentioned above re remove template namespace probably can be removed now ... but is also orthogonal
2. right now, the create flow always passes in the arg to set the namespace from what was specified in the withProject method ... just need to allow for honoring the obj namespace if it exists

from jenkins-client-plugin.

right now, the create flow always passes in the arg to set the namespace from what was specified in the withProject method ... just need to allow for honoring the obj namespace if it exists

sounds right. presumably that's what "oc process -f foo | oc create -f -" does.

from jenkins-client-plugin.

Another train of thought:

1. when @alanbchristie cites he did a oc process -f <template-file> | oc create -f -, was it preceded by something like an oc login and then oc project Y beforehand; or did an oc cluster up and got that activity under the covers

2. this separation, if this is in fact what was done using the CLI, is a key difference ... with this plugin, there is not an oc login that occurs when we call openshift.withCluster, nor an oc project associated with openshift.withProject. Those instead become the --namespace and --serverURL / --token / --ca-crtetc. args on a singleoc` invocation. That makes approximating the defaulting behavior a little trickier.

I've circled back around to having to iterate through the api object list, and if namespaces are specified, adjust accordingly, along with seeing if I can avoid multiple oc create calls.

I'll try to put something together in a PR and we all can then review it and see how it looks. But I'm not convinced yet that the work around that @alanbchristie came up with might not be more attractive resolution.

from jenkins-client-plugin.

update: I have create and access for this scenario working with the process and create verbs used in tandem.

the new-app path is different though, and needs similar adjustments.

i'll submit a PR once that is sorted out

from jenkins-client-plugin.

update: the changes in the referenced PR are passing both new multiproject tests as well as regression tests.

however, given the amount of change needed to make this work, we want to hold off on a new version of the plugin and update to the openshift jenkins images until after the soon to be release 3.9 of openshift is cut.

we can entertain plugin versions published to the jenkins update center with the fix after we cut the 3.9 branch at https://github.com/openshift/jenkins if that would help users in the interim.

@alanbchristie - with all that, and the workaround noted in the description, do you have any feel on how soon you need this? Or how long you can wait?

thanks

from jenkins-client-plugin.

from jenkins-client-plugin.