Create OpenShift Resource(s) task tries to create resource in wrong project about jenkins-plugin HOT 10 CLOSED

Yep, we don't currently parse the json/yaml for namespace specifications and adjust the REST call accordingly. Same goes for the resource deletion steps.

We minimally need to document the behavior, if not change the implementation to handle this.

@bparees - any initial opinions on what we want to do here (I'm leaning toward code change, but with the background around create/delete, I don't think it is a given)

from jenkins-plugin.

not certain i understand the behavior.

if the resource being created does NOT itself define a namespace in the metadata, does it get created in the namespace defined by the build step (and defaults to the current jenkins namespace)?

and if the resource does define a namespace in the metadata, does it get created in that namespace?

from jenkins-plugin.

On Fri, Jul 1, 2016 at 11:32 AM, Ben Parees [email protected]
wrote:

not certain i understand the behavior.

if the resource being created does NOT itself define a namespace in the
metadata, does it get created in the namespace defined by the build step
(and defaults to the current jenkins namespace)?

and if the resource does define a namespace in the metadata, does it get
created in that namespace?

Right now the create build step always creates all resources in the
namespace specified in the create build step config (or if none is
specified there, it uses the namespace of the jenkins service mounted into
the pod
for all objects it creates), using the auth token specified (where if if
none is specified, it using the one for the service account mounted into
the pod).

It ignores any specification of resource in the JSON/YAML. Aside from
doing basic JSON/YAML format verification, we stop parsing the JSON at the
'kind' (we need to know the 'kind'
to know which REST endpoint to hit).

Manipulating resources in other namespaces of course gets into either
giving the jenkins serivce account edit access to those namespaces, or
providing auth tokens for any namespace
noted in the JSON/YAML.

If we want to go down this path, the timing of any changes is also a
consideration (at some point we'll want to move to a newer version of the
openshift-restclient-java component, where they
have improved the API around generic resource creation, which we might want
to switch to).

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#45 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ADbadP4XwcAx5-FO40lyrbJLnMmYJdIXks5qRTMTgaJpZM4JDF2B
.

from jenkins-plugin.

what does "oc create -f foo.yaml -n somenamespace" do when foo.yaml specifies a namespace? we should expect to align with that.

from jenkins-plugin.

On Fri, Jul 1, 2016 at 2:34 PM, Ben Parees [email protected] wrote:

what does "oc create -f foo.yaml -n somenamespace" do when foo.yaml
specifies a namespace? we should expect to align with that.

Good point. Unless someone beats me to it, I'll give it a go next chance I
get, report back, and we'll go from there.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#45 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ADbadKZiGr7jV73R12wudEyzGopf-miDks5qRV2rgaJpZM4JDF2B
.

from jenkins-plugin.

Note that in this case I did NOT set a namespace in the yaml text field.

I did however put a namespace/projectname in the text filed that say "The name of the project to create the resource in". I would have thought that this was the equivalent to having "-n demo" on the commandline when calling the oc binary. However this namespace/projectname is ignored.

So it is not (at least not in my case) a problem where the "-n" say one thing and the yaml another.

from jenkins-plugin.

FYI - I've reproduced this and am working on a fix.

from jenkins-plugin.

So I believe the problem where the namespace specified in the build step field was not used was introduced with commit 373afaa (from about 4 weeks ago).

This bug actually affects all the build steps, not just the create resources one. So I'm bumping the priority to p2.

With the fix I will soon commit, if you specify a project that is different from the project jenkins is running in, as well as the associated default service account token for said project, and as well as providing the default service account token edit access for said project, you can create resources.

For honoring the namespace within the json/yaml, I'm going to look into a fix of the following form:

• the token provided to the step has been given edit access to any project listed in the json/yaml (the doc will be updated with this requirement); I don't want to introduce a change where we specify multiple tokens for each project
• i'll then fetch a rest client to the specific namespace as part of processing each resource

If this change proves straightforward, I'll include it in the fix as well. Otherwise, I'll just incorporate the fix to honor the namespace, and document the restriction of not honoring the namespace in the json/yaml for now, and track lifting this restriction our trello card that is handling rebasing the plugin on the newer version of the rest client.

from jenkins-plugin.

OK, I got the pulling of the namespace from the json/yaml working easily enough. Will include this change, along with the doc updates mentioned previously around permissions for the service account.

from jenkins-plugin.

Delivered fixes with 895c47b

Built, pre-release version of the plugin with this change can be found here

When it comes out, V1.0.21 will be the official release with the fix.

Closing this out - please reopen if something does not seem right wrt the fix provided.

from jenkins-plugin.