Task status is Unknown when using exec as entry point style

[umutcann]

Hi,

While using shell as entry point style, If batch kubernetes pod has finished error, task status is error like below.

But we want to launch task using exec due to restart problem in the case.

And when we try to launch task using exec, task status is still unknown although pod has error and batch app finish error.

Do you have any idea about this issue?

Thanks.

[cppwfs]

It looks like the Task failed to start. Check your task's log, to see if it threw an exception. If there is no Pod for the task, check SCDF's log to see if there is an exception when attempting to launch the task. If this can't provide you the information you need to resolve the problem you can share the logs with us. Also what version of SCDF are your using?

[umutcann]

Hi @cppwfs

We are using 2.7.0-RC1 version. There are pods on kubernetes for both shell and exec. And two of them are failing same error.

Let me clarify something. I am trying to test restart task capability of scdf. So I'm generating error for task intentionally.

When I used shell as entry point style, I am able to see failed step and exit message like below.

But when I used exec, pod status is still unknown although pod is failed with same error.

I hope that I am able to describe issue.

Please inform me if you have any other question.

Thanks in advance.

[cppwfs]

Hello @umutcann Can you provide a sample app that displays this failure so I can retry it on my side.
Also how are you building your container for the application (Spring Boot, jib, Dockerfile, other)?

The steps you reproduce the problem:

1. Launch Task/Batch boot application on SCDF. (It is expected to fail)
2. Restart Failed Task/Batch boot application. (it is expected to fail)
3. Check the status of application and verify that 2 failed Task Executions are present.

[umutcann]

Hi @cppwfs,

I am not able to share our sample app due to restrictions of corporate data security. I'm sorry about that.

We are building our spring batch apps using s2i build strategy of RedHat Openshift. We are building source code using maven after that we are creating image using build config.

And I couldn't understand steps which you mentioned above. Because I'm not restarting failed task using as it's status is unknown using exec.

Please let me know, If I understand wrongly.

Kind regards.

[umutcann]

Hi @cppwfs ,

Is there any update regarding issue?

Do you need any other thing to investigate issue?

[cppwfs]

Currently we are supporting containers created by Spring Boot, Jib and, Dockerfile.
Can you provide a simple application that replicates the problem along with the associated scripts used in the --scripts-url directory, that you are using for the S2I container build.

[umutcann]

Hi @cppwfs

I was working on the problem.

I guess I find root cause of problem.

SCDF is creating a task, and creates a new pod in openshift to execute the task, but, in this pod, instead of updating the details of the task, it is creating a new one:

In the logs of the corresponing pod, you can see the details of the task and the job id

We can see the task execution 28026 in scdf console, including references to the corresponding job, although the details of the task are missing (the new record is not properly populated)

Execution 28026 cannot be restarted as the task it is referring to is not existing.

This is working propertly in case we use entryPointStyle=shell

Do you still need a sample application?

[cppwfs]

Spring Cloud Data Flow creates a task execution row in the task_execution table when it launches a task. It then passes the spring.cloud.task.executionid property to the task containing the task execution id for the task to use. The task then uses this id to update its task execution information. The task is behaving like the spring.cloud.task.executionid is not being passed to the task. But the image above does not show the properties, so I can't be sure. You need to make sure that your container is passing all the properties from dataflow to the task application.