nodejs 2.0 and 2.2 devfiles use terminating image under the hood and not usable by Eclipse Che

[ibuziuk]

Which area this bug is related to

/area registry

Bug Summary

The following nodejs devfiles are using registry.access.redhat.com/ubi8/nodejs-14:latest image under the hood. The image is not usable by Eclipse Che / CRW since it is a terminating one, and does not specify non-terminating command / args.

Affected devfiles:

• https://registry.devfile.io/devfiles/nodejs
• https://registry.devfile.io/viewer/devfiles/Community+nodejs-basic (uses https://registry.devfile.io/devfiles/nodejs as parent)

Expected behavior

Workspace is started without errors

Any logs, error output, screenshots etc? Provide the devfile that sees this bug, if applicable.

runtime container which uses registry.access.redhat.com/ubi8/nodejs-14:latest puts the pod in the CrashLoopBackOff state

Additional context

The problem has been already raised in #681 (comment)

Any workaround?

N/A

Suggestion on how to fix the bug

Update the image and make it non-terminating

[johnmcollier]

Believe this will be fixed by devfile/registry#91

[ibuziuk]

@johnmcollier thanks for the pointer, however, I do not see any changes in this draft PR related to ubi8/nodejs-14:latest update.
Could this issue be prioritized accordingly because currently 2.2 sample is non-working

[kadel]

We will have to specify container.command in most of the stack and sample devfiles.

@ibuziuk What would be the ideal command to make images non-terminating? sleep inifinity? cat > /dev/null?

We should document what is the recommended way to do this. Most of the images that we are going to use in devfile stack will have default entrypoint that is terminating.So we will have to remember override it in devfiles.

[ibuziuk]

What would be the ideal command to make images non-terminating

@kadel we normally use tail -f /dev/null

We should document what is the recommended way to do this. Most of the images that we are going to use in devfile stack will have default entrypoint that is terminating. So we will have to remember override it in devfiles.

👍 please, let me know if you need assistance with this

[l0rd]

Note that this PR would fix this issue (it adds container.command: ["tail", "-f", "/dev/null"] to all the terminating containers) but odo doesn't like that. So we are blocked.

[johnmcollier]

@kadel do you have any suggestions here? It seems overriding the command to the devfile causes odo to fail to deploy the devfile since supervisord isn't the entrypoint any more.

[kadel]

@kadel do you have any suggestions here? It seems overriding the command to the devfile causes odo to fail to deploy the devfile since supervisord isn't the entrypoint any more.

Yes, sadly this is a bug in odo :-/ We should have a fix in a few days.
We should wait before merging this change until we have a new odo release with this fix.
But even after that, this change will break all previous odo versions :-/

[schultzp2020]

@kadel has odo released a fix?

[kadel]

@schultzp2020 yes, a while back. More info is in the PR comments (devfile/registry#102 (comment))

[johnmcollier]

@ibuziuk Can this issue be closed out?

[l0rd]

This issue has been resolved. There is a PR check that verifies that there are no more terminating containers in the registry.