Unable to run simple hello world application on OpenShift with quarkus.kubernetes.deployment-target=knative

[rsvoboda]

I have simple https://github.com/rsvoboda/openshift-quickstart project for Knative Serving experiment. I have OpenShift 4.5 with OpenShift Serverless - Knative Serving installed.

I'm unable to run simple hello world application on OpenShift with quarkus.kubernetes.deployment-target=knative

Steps to reproduce
See README.md in https://github.com/rsvoboda/openshift-quickstart

Some details:
The application uses quarkus-openshift extension and sets quarkus.kubernetes.deployment-target=knative in https://github.com/rsvoboda/openshift-quickstart/blob/master/src/main/resources/application.properties#L3

mvn clean package -Dquarkus.kubernetes.deploy=true succeeds, but the service on the cluster can't start.

Service gets available when I change quarkus.kubernetes.deployment-target to openshift :/.

https://quarkus.io/guides/kubernetes#knative doesn't mention any additional changes.

More details:
https://console-openshift-console.apps.ocprs.dynamic.quarkus/k8s/ns/rsvoboda/serving.knative.dev~v1~Service/openshift-quickstart says:

Revision "openshift-quickstart-b5zmr" failed with message: Unable to fetch image "rsvoboda/openshift-quickstart:1.0-SNAPSHOT": failed to resolve image to digest: failed to fetch image information: GET https://index.docker.io/v2/rsvoboda/openshift-quickstart/manifests/1.0-SNAPSHOT: UNAUTHORIZED: authentication required; [map[Action:pull Class: Name:rsvoboda/openshift-quickstart Type:repository]].

Log from terminal shows, that the image push was successful:

[INFO] [io.quarkus.container.image.s2i.deployment.S2iProcessor] Pushing image image-registry.openshift-image-registry.svc:5000/rsvoboda/openshift-quickstart:1.0-SNAPSHOT ...
[INFO] [io.quarkus.container.image.s2i.deployment.S2iProcessor] Getting image source signatures
[INFO] [io.quarkus.container.image.s2i.deployment.S2iProcessor] Copying blob sha256:96d330a26895c15953dadd5a7cda8801a777e3b49a21bb0f1d5e3006042399d9
[INFO] [io.quarkus.container.image.s2i.deployment.S2iProcessor] Copying blob sha256:6d7d25eb85759731f9e5726883604d83d1a9f15e2e37ca0bf7c200e638762eef
[INFO] [io.quarkus.container.image.s2i.deployment.S2iProcessor] Copying blob sha256:332a2e4ef6a26a451b89acbc5c7f57d631e64a554a62298403b5b4ea205241b0
[INFO] [io.quarkus.container.image.s2i.deployment.S2iProcessor] Copying blob sha256:25f07378c750b25e33c2e34d53f05f1f14a320217c294f43ef7835b96db2d8ae
[INFO] [io.quarkus.container.image.s2i.deployment.S2iProcessor] Copying config sha256:4fb64a5451f7fd863efafbd6424b12980f9d963c1620e8e0141753038d1ad832
[INFO] [io.quarkus.container.image.s2i.deployment.S2iProcessor] Writing manifest to image destination
[INFO] [io.quarkus.kubernetes.deployment.KubernetesDeployer] Deploying to knative server: https://api.ocprs.dynamic.quarkus:6443/ in namespace: rsvoboda.
[INFO] [io.quarkus.kubernetes.deployment.KubernetesDeployer] Applied: ServiceAccount openshift-quickstart.
[INFO] [io.quarkus.kubernetes.deployment.KubernetesDeployer] Applied: Service openshift-quickstart.
[INFO] [io.quarkus.deployment.QuarkusAugmentor] Quarkus augmentation completed in 71900ms

@geoand or @Ladicek can you take a look?

[geoand]

Seems like s2i is being used which probably should not be the case when using knative as the deployment target.

cc @iocanel

[Ladicek]

I don't know anything about Knative, sorry.

[quarkusbot]

/cc @geoand

[geoand]

This is probably just a matter of disabliing s2i deployment when knative is used

[rsvoboda]

How can it be done? Can you fork and adjust https://github.com/rsvoboda/openshift-quickstart?

[geoand]

I'm still on PTO.

It should just be a matter of not including the Openshift extension - but regardless, we need to make it work even if the Openshift extension is present.

[rsvoboda]

Well, OpenShift extension should handle OpenShift Serverless - Knative Serving scenario.
I'm expecting this extension to be the main entry point from RH product portfolio perspective.

[rsvoboda]

@geoand enjoy the rest of your vacation, response to GH issues can wait till you are officially back ;)

[geoand]

Thanks 👍

I'll take a look as soon as I get back

[tqvarnst]

I've investigated this a bit and there seems to be an issue with the image: tag in the generated knative.yml. I'm not sure why and we might wanna confirm this with the Serverless team, but it seems that you need to set the full image path including the registry to pull from. By setting this to image-registry.openshift-image-registry.svc:5000/<namespace>/<image-stream> it successfully deploys.

By the way, the generated namespace also is wrong and defaults to my username.

[rsvoboda]

I got finally back to this and I tried to to explicitly specify the registry - image: image-registry.openshift-image-registry.svc:5000/rsvoboda/openshift-quickstart:1.0-SNAPSHOT.
There were some troubles because when I executed oc apply -f target/kubernetes/knative.yml after mvn clean package -Dquarkus.kubernetes.deploy=true I still didn't get the app running.
There were also some warnings which confused me a bit.

Warning: oc apply should be used on resource created by either oc create --save-config or oc apply
serviceaccount/openshift-quickstart configured
Warning: oc apply should be used on resource created by either oc create --save-config or oc apply
service.serving.knative.dev/openshift-quickstart configured

I created ~/Downloads/my-knative.yml which used openshift-quickstart-rs name instead of openshift-quickstart to avoid the above warning.

In OpenShift Activity view for events I saw message about created rsvoboda/openshift-quickstart:1.0-SNAPSHOT image ~2 minutes after mvn command, this was probably the reason why my previous attempts didn't work.

After calling oc apply -f ~/Downloads/my-knative.yml I was able to see openshift-quickstart-rs route under Serverless section of the we console and the app under http://openshift-quickstart-rs-rsvoboda.apps.ocprs.dynamic.quarkus/

So in the end I made my sample app work on OpenShift Serverless but I had to use adjust the yaml and use oc tool and it wasn't too great experience as I had to try few times.

[geoand]

By the way, the generated namespace also is wrong and defaults to my username.

Actually this is consistent with how the extension behaves for regular Kubernetes deployments. The username is used as the default when quarkus.container-image.group is not set.

[geoand]

I just tried this and it workd flawlessly when two small configuration settings are applied (no other changes needed):

# set the namespace
quarkus.container-image.group=geoand 
# set the container image registry
quarkus.container-image.registry=image-registry.openshift-image-registry.svc:5000

From my PoV, what is missing is some documentation, which I will add now.

[Ladicek]

This totally sounds like something users shouldn't have to do themselves, in case of OpenShift. We probably could distinguish regular Knative and OpenShift Serverless (either via an extension, e.g. quarkus-openshift-serverless, or via deployment target, e.g. quarkus.kubernetes.deployment-target=openshift-serverless), but I don't know anything about Knative, so I should probably stay silent :-)

[geoand]

@Ladicek yeah, that is definitely an option.

I am kind of on the fence however since I am a little worried it will make things more confusing.
If however everyone agrees with your proposal, I'll gladly implement it

[rsvoboda]

Agree with @Ladicek, this is something users shouldn't have to do themselves. I'm slightly more in favor of quarkus.kubernetes.deployment-target=openshift-serverless way instead of introducing another extension,

@tqvarnst, please share your view on this.

[geoand]

Reopening this as we might want a zero-config solution

[geoand]

Closing, for now