Improve the "oc new-app" build task about jenkins-plugin HOT 12 CLOSED

Yep, adding an oc new-app equivalent to the plugin has come up before. There has been reluctance to do so in the past, but the votes keep coming in.

We can use this item to have another round of the discussion.

A couple of follow up questions to you @ullgren to drill down on the scenario:

1. What advantages to you see from doing it from the plugin vs. doing it from either the command line outside of jenkins, or from a sh 'oc new-app ...' call out from a jenkins job (since we bundle the oc binary in the openshift jenkins image) ?

2. Do you see the inputs into an oc new-app equivalent being dynamic in any way, based on the output from prior steps?

thanks

@bparees @smarterclayton FYI

from jenkins-plugin.

yeah i'm still pretty reluctant, especially since you can always invoke oc new-app via a shell command step. If we did do it, I think the only realistic way we can implement it is as a system call from the plugin to the oc command line anyway (there is no server side api for new-app, it's all client side logic which we aren't going to re-implement in the plugin).

But i'm definitely interested in the answer to (1).

from jenkins-plugin.

1. Two main reasons:
   A) I do not always run Jenkins as a OSE application. I have some setups where I have a separate Jenkins setup already in place that I just want to communicate with an existing OpenShift cluster. It is then more convenient to use a plugin that relay on a system binary beeing installed.

B) Convenience for persons that are not familiar with oc commands (or shell scripting). It is simpler for them to get a fixed set of input fields with help text than just a text field where to put arbitrary shell scripts.

But I was not aware that this was done client side and not server side. Given that I do see the reluctance to reimplement this logic in the plugin. However with the same logic all plugin build steps are then unnecessary since all can be done from exec task using the oc binary. :-)

2. Yes at least dynamic in the way that I can set template parameters using envvars set by Jenkins and other plugins. For instance be able to create a new app with the name $BUILD_TAG

from jenkins-plugin.

Also if it is not implemented you should probably put something in the README under the "Jenkins "build steps"" section that this is not and will not be implemented and suggest to use the oc binary instead.

Or I guess the request will keep popping up :-)

from jenkins-plugin.

However with the same logic all plugin build steps are then unnecessary since all can be done from exec task using the oc binary. :-)

sure, that's the logical conclusion, but obviously we prefer to provide a useful wrapper/parameterization/checking where we can. just doesn't look like new-app will be one of those places.

Also if it is not implemented you should probably put something in the README under the "Jenkins "build steps"" section that this is not and will not be implemented and suggest to use the oc binary instead.
Or I guess the request will keep popping up :-)

sure we can do that w/ a link to this issue.

from jenkins-plugin.

Some embedded response below.

@bparees - there might be enough here to open a trello card and/or add a
topic to upcoming futures discussions ... thoughts?

On Fri, Jul 1, 2016 at 4:04 PM, Pontus Ullgren [email protected]
wrote:

1. Two main reasons:
   A) I do not always run Jenkins as a OSE application. I have some setups
   where I have a separate Jenkins setup already in place that I just want to
   communicate with an existing OpenShift cluster. It is then more convenient
   to use a plugin that relay on a system binary beeing installed.

Gotcha - yep, I'm always curious to hear whether folks are using the plugin
in a Jenkins not running under OpenShift.

wrt oc new-app in particular, as @bparees mentioned, most likely if we
exposed something it would entail a process fork of the oc binary (there
is not a "new-app" api endpoint), and hence would require Jenkins running
under OpenShift.
that said, we could provide some value add in taking Jenkins env vars and
automatically mapping them to new-app parameters perhaps

B) Convenience for persons that are not familiar with oc commands (or
shell scripting). It is simpler for them to get a fixed set of input fields
with help text than just a text field where to put arbitrary shell scripts.

But I was not aware that this was done client side and not server side.
Given that I do see the reluctance to reimplement this logic in the plugin.
However with the same logic all plugin build steps are then unnecessary
since all can be done from exec task using the oc binary. :-)

Yep, the conundrum with the plugin :-) ... but as you implied in 1B), the
value of the plugin really is to more familiar and comfortable with Jenkins
jobs than oc, etc. The balancing act is where to draw the line wrt fully
re-implementing oc

2. Yes at least dynamic in the way that I can set template parameters
   using envvars set by Jenkins and other plugins. For instance be able to
   create a new app with the name $BUILD_TAG

Interesting ... but yeah, this is what I was curious about ... whether in
the Jenkins scenarios if users wanted the names of things to be dynamic and
based off of Jenkins build "metadata" if you will

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

from jenkins-plugin.

On Fri, Jul 1, 2016 at 4:07 PM, Pontus Ullgren [email protected]
wrote:

Also if it is not implemented you should probably put something in the
README under the "Jenkins "build steps"" section that this is not and will
not be implemented and suggest to use the oc binary instead.

Or I guess the request will keep popping up :-)

Heh :-) .... at least for me, I've wanted to avoid making definitive "will
not be implemented" statements in this area, and am good for now at least
if the issues keep popping up. If the demand is there, we want to have the
conversations with our users,
understand the scenarios, and figure out workable solutions.

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

from jenkins-plugin.

most likely if we exposed something it would entail a process fork of the oc binary (there is not a "new-app" api endpoint), and hence would require Jenkins running under OpenShift.

or just having the oc binary on your jenkins host.... right? all the credentials and other stuff i assume we allow you to provide in other ways so we don't need the /var/run/secrets service account file.

@bparees - there might be enough here to open a trello card and/or add a topic to upcoming futures discussions ... thoughts?

it'd be a good arch call topic, but my position is that unless we rewrite new-app to be a server side endpoint, we wouldn't do this. and it'd be hard to implement as a server side endpoint since you need to do things like source detection, which requires access to the local source (or at a minimum access to a git repo if the source is in a git repo). it gets hairy fast.

a poor-man's new-app in which you tell the server "i know my source type is ruby, figure out the rest" might be an option, if we went down that path at all. again, arch call topic. :)

from jenkins-plugin.

(in case my reponse wasn't clear: i don't want to open a trello card for it at this point)

from jenkins-plugin.

But I was not aware that this was done client side and not server side.
Given that I do see the reluctance to reimplement this logic in the plugin.
However with the same logic all plugin build steps are then unnecessary
since all can be done from exec task using the oc binary. :-)

Yep, the conundrum with the plugin :-) ... but as you implied in 1B), the
value of the plugin really is to more familiar and comfortable with Jenkins
jobs than oc, etc. The balancing act is where to draw the line wrt fully
re-implementing oc

If the option is to have a process fork of the oc binary I personally would rather see you do not implement it (since it would add a requirement to have the oc binary). Then instead document it and let users decide them self when to do process forks.
As I wrote above when I posted the request I was not aware that this was not part of the server API. Since it isn't I fully understand your reluctance to implement it.

2. Yes at least dynamic in the way that I can set template parameters
   using envvars set by Jenkins and other plugins. For instance be able to
   create a new app with the name $BUILD_TAG
   Interesting ... but yeah, this is what I was curious about ... whether in
   the Jenkins scenarios if users wanted the names of things to be dynamic and
   based off of Jenkins build "metadata" if you will

Yes the usecase is to create a new app (with services) as part of the jenkins build, build, run tests and then delete it. If we can name it using the build tag it would really help.

from jenkins-plugin.

OK, we (the team @bparees and I are on) can still have the arch call discussion, but short term, we'll keep this open, and I'll think about how to precisely address this in the README (I think documenting this is conceivably a slippery slope as well).

When ready I'll open a PR for the three of us to review the doc change.

from jenkins-plugin.

or just having the oc binary on your jenkins host.... right? all the credentials and other stuff i assume we > allow you to provide in other ways so we don't need the /var/run/secrets service account file.

Yes that would work. But it is not always we have access to installing system binaries (or even have system accounts). Installing a plugin however we can do from Jenkins. And yes we can work around this by doing a Jenkins job that, using shell tasks, wget the oc binary and installs it. However I guess some grumpy sysadmin character will say some grumpy things about Java developers if we do that :-)

from jenkins-plugin.