FR: Permissive mode for the resources creation build step

[livelace]

Hello. We use the "Create Openshift Resource(s)" build step for dynamic (specific names and parameters) configurations. The executed configurations are usually deleted, but we need that some resources could have existed after deletion and they couldn't have been cause an error. For instance:

1. Create: a build configuration with name "bc-ubuntu-run", an image stream with name "is-ubuntu-run"
2. Build this configuration and tag the image stream.
3. Delete builds and the build configuration. Image stream is still exist for projects, which use it for their work, we don't have to delete it.

1. Create: a build configuration with name "bc-ubuntu-run", an image stream with name "is-ubuntu-run" -> this is cause of the error, because image stream already exists. What we do now - we must create all image streams (a lot of) before the configuration will be executed. It would be very useful if we can set flag "supress the errors of the resource existence".

[gabemontero]

Probably is just a matter of catching the exception when we have a list of resources. I'll confirm when I get into the office and if so make the quick change.

On Wednesday, October 19, 2016, Oleg Popov notifications@github.com wrote:

Hello. We use the "Create Openshift Resource(s)" build step for dynamic (specific names and parameters) configurations. The executed configurations are usually deleted, but we need that some resources could have existed after deletion and they couldn't have been cause an error. For instance:

1. Create: a build configuration with name "bc-ubuntu-run", an image stream with name "is-ubuntu-run"
2. Build this configuration and tag the image stream.
3. Delete builds and the build configuration. Image stream is still exist for projects, which use it for their work, we don't have to delete it.
4. Create: a build configuration with name "bc-ubuntu-run", an image stream with name "is-ubuntu-run" -> this is cause of the error, because image stream already exists.

What we do now - we must create all image streams (a lot of) before the configuration will be executed. It would be very useful if we can set flag "supress the errors of the resource existence".

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openshift/jenkins-plugin/issues/96, or mute the thread https://github.com/notifications/unsubscribe-auth/ADbadB-HLY3j7jB2_mvl5glfq7b52pbcks5q1dY5gaJpZM4Kasvd .

[gabemontero]

theory confirmed

[gabemontero]

fixed delivered with https://github.com/openshift/jenkins-plugin/commit/d1286d73a51f88c4c868fa9abe804a6f5561a588

I'll start the process of cutting a new official version (v1.0.24) of the plugin by the end of this week

[livelace]

@gabemontero So fast! Thanks a lot:)

[livelace]

Fix doesn't work:

Starting "Create OpenShift Resource(s)" with the project "images".

OpenShiftCreator calling create on for type imagestreams and resource { "apiVersion" : "v1", "kind" : "ImageStream", "metadata" : {"name" : "testing-drweb-workstations-ubuntu-14.04"} } Auth - allowCertificate with incoming chain of len 2 Auth - in skip tls mode, returning true com.openshift.restclient.OpenShiftException: Exception trying to POST https://openshift-master1.i.drweb.ru:8443/oapi/v1/namespaces/images/imagestreams response code: 409 imagestreams "testing-drweb-workstations-ubuntu-14.04" already exists at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.createOpenShiftException(ResponseCodeInterceptor.java:114) at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:65) at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92) at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67) at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:170) at okhttp3.RealCall.execute(RealCall.java:60) at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:217) at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:194) at com.openshift.jenkins.plugins.pipeline.model.IOpenShiftCreator.makeRESTCall(IOpenShiftCreator.java:61) at com.openshift.jenkins.plugins.pipeline.model.IOpenShiftCreator.coreLogic(IOpenShiftCreator.java:87) at com.openshift.jenkins.plugins.pipeline.model.IOpenShiftPlugin.doItCore(IOpenShiftPlugin.java:299) at com.openshift.jenkins.plugins.pipeline.model.IOpenShiftPlugin.doIt(IOpenShiftPlugin.java:312) at com.openshift.jenkins.plugins.pipeline.OpenShiftBaseStep.perform(OpenShiftBaseStep.java:81) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:782) at hudson.model.Build$BuildExecution.build(Build.java:205) at hudson.model.Build$BuildExecution.doRun(Build.java:162) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534) at hudson.model.Run.execute(Run.java:1738) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:410) Failed to create a "ImageStream"

1.0.24 + 1.0.25

[gabemontero]

Perhaps we had a miscommunication. If the object already exists, like the image stream in your example, it is still going to fail to create.

Hence the message in the output you posted:

com.openshift.restclient.OpenShiftException: Exception trying to POST https://openshift-master1.i.drweb.ru:8443/oapi/v1/namespaces/images/imagestreams response code: 409 imagestreams "testing-drweb-workstations-ubuntu-14.04" already exists

I didn't change the code to delete the imagestream and recreate. Is that what you were expecting? That was not intended with my change (nor am I even sure we'd want to introduce such a change).

However, we will continue to attempt to create the other resources in your list. Looking at the stack trace you posted:

at com.openshift.jenkins.plugins.pipeline.model.IOpenShiftCreator.makeRESTCall(IOpenShiftCreator.java:61)
at com.openshift.jenkins.plugins.pipeline.model.IOpenShiftCreator.coreLogic(IOpenShiftCreator.java:87)

The call to makeRESTCall from coreLogic at line 87 is now surrounded by a try / catch (Throwable):

                try {
                    success = this.makeRESTCall(chatty, listener, path, node, overrides);
                } catch (Throwable t) {
                    if (chatty)
                        t.printStackTrace(listener.getLogger());
                }

The OpenShiftException will not escape that block.

[livelace]

@gabemontero

I didn't change the code to delete the imagestream and recreate. Is that what you were expecting?

No-no-no, we just want that this error was not an exception. Can you add "ignore an existing image stream" checkbox for this build step ?

[gabemontero]

Ah ok.

First we don't print the exception unless verbose logging is on. That could serve as your control.

Adding an ignore option like you have outlined is too specific and special case.

We might be able to determine that the item already exists and print "already exists" instead of "failed". If that is agreeable let me know, but such a change won't make this dev cycle / release.

On Friday, October 21, 2016, Oleg Popov notifications@github.com wrote:

@gabemontero https://github.com/gabemontero

I didn't change the code to delete the imagestream and recreate. Is that what you were expecting?

No-no-no, we just want that this error was not an exception. Can you add "ignore an existing image stream" checkbox for this build step ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openshift/jenkins-plugin/issues/96#issuecomment-255368016, or mute the thread https://github.com/notifications/unsubscribe-auth/ADbadOyd8QBzgSmxa6zj4iWGI9oJFFcbks5q2LIrgaJpZM4Kasvd .

[livelace]

@gabemontero

It isn't important what a build step wrote ("already exist" or "failed"). It's important that this build step doesn't put the whole task in failed state. We need that the task could stay in working state despite of the existing ImageStream.

We have started to use two Jenkins task:

1. The first task just tries to create ImageStream and despite of results (success or failed) it calls the second task.
2. The second task creates Deployments and other things.

This trick allows not to create all possible image streams with different names (dynamic configurations, you are remember).

[gabemontero]

Ok so a config option that says mark the step as succeeding if at least 1 create succeeds. Certainly more manageable. I'll see if we can squeeze this in as part of wrapping up the upcoming release and if not I'll get a trello card opened to have it considered for the next release. Thanks for the clarification.

FYI @bparees

On Wednesday, October 26, 2016, Oleg Popov notifications@github.com wrote:

@gabemontero https://github.com/gabemontero

It isn't important what a build step wrote ("already exist" or "failed"). It's important that this build step doesn't put the whole task in failed state. We need that the task could stay in working state despite of the existing ImageStream.

We have started to use two Jenkins task:

1. The first task just tries to create ImageStream and despite of results (success or failed) it calls the second task.
2. The second task creates Deployments and other things.

This trick allows not to create all possible image streams with different names (dynamic configurations, you are remember).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openshift/jenkins-plugin/issues/96#issuecomment-256248087, or mute the thread https://github.com/notifications/unsubscribe-auth/ADbadGd1fnlcxCPdVCIrIgJAFS2YVCMCks5q3tpYgaJpZM4Kasvd .

[livelace]

@gabemontero Thanks!