apache/camel-k

Nicola Ferraro

@nicolaferraro

We have some e2e tests for that. The first one is a deployment that calls a knative service (the service is still made with camel k): https://github.com/apache/camel-k/blob/120bdea7456e85a4aa3cc1f4a986ac8533bd28d5/e2e/knative_test.go#L32

Note that I've found some issues with mapping of cloud events, that are solved in 1.0.7-SNAPSHOT or 1.0.6 currently staged here https://repository.apache.org/content/repositories/orgapachecamel-1160

of the runtime

but that should not happen in your case because your the recipient service does not check those headers (and the error in case is not 502 but 4xx)

Luca Morandini

@lmorandini

One thing I noticed is that error comes from org.apache.camel.k.camel-knative-http-1.0.5.jar rather than the 1.0.6 version of that JAR, despite having used the 1160 repo to build it.

Could you please check my Camel-K build commands?

cd ../camel-k
  chmod a+x kamel
  make clean
  make --always-make
  make imgDestination='docker.io/lmorandini' images
  docker tag apache/camel-k:${KAMEL_VERSION} docker.io/lmorandini/camel-k:${KAMEL_VERSION}
  docker push docker.io/lmorandini/camel-k:${KAMEL_VERSION}
  ./kamel install\
    --registry-insecure\
    --registry asia.gcr.io\
    --registry-secret kaniko-secret\
    --organization ${PROJECT_ID}\
    --maven-repository 'https://repo.maven.apache.org/maven2'\
    --maven-repository "https://repository.apache.org/content/repositories/orgapachecamel-${KAMEL_REPO_VERSION}"\
    --operator-image docker.io/lmorandini/camel-k:${KAMEL_VERSION}\
    --kaniko-build-cache=false\
    --namespace ${NAMESPACE}\
    --wait

(KAMEL_VERSION is '1.0.0-M4-SNAPSHOT' and KAMEL_REPO_VERSION is '1160`.)

Nicola Ferraro

@nicolaferraro

I think you need to set RUNTIME_VERSION to 1.0.6 in the Makefile and make codegen before building the image..

Luca Morandini

@lmorandini

@nicolaferraro no joy. I even changed 1.0.5 in 1.0.6 RUNTIME_VERSION_CONSTRAINT, but still 1.0.5 is deployed.

Nicola Ferraro

@nicolaferraro

make build-resources should also add an embedded camel catalog for 1.0.6

I think it would choose 1.0.5 without that

Luca Morandini

@lmorandini

And 1.0.6 it was finally (I think it was due to a mix-up with container registries, my bad).

Luca Morandini

@lmorandini

I think I found out why my integration cannot reach a KNative service using the HTTP protocol (instead of the knative one): the KnativeHttpProducer class of camel-k-runtine sets the Host header, which unfortunately is the one used by Knative for routing.
Is it so by design or may this be changed?

Luca Burgazzoli

@lburgazzoli

you can set the host header on the route

btw, why not using the knative component?

just asking so we can improve it if it lacks something

Nicola Ferraro

@nicolaferraro

Knative leverages the service mesh, so once requests enter istio, the host header is the only way route them

Luca Morandini

@lmorandini

I set the host header in the route, but the class I mentioned sets it (KnativeHttpProducer.java line 93)... and I wasn't able to make the "knative" protocol work.

Luca Burgazzoli

@lburgazzoli

sorry but I'm little confused now: is the fact that knative component set the host a problem ? in your previous message what I understood is that the problem is that the http component does not set it

Luca Morandini

@lmorandini

...no no, it is the class that overwrites it (plz have a look at the source code in camel-k-runtime).

Luca Burgazzoli

@lburgazzoli

the knative component sets the header according to what camel-k looks up from the cluster so yes, with the knative protocol you can't override the host header as it is computed by camel-k

Luca Morandini

@lmorandini

Hmm, KnativeHttpProducer set the host header to the hostname regardless.

...it is always rewritten, ditto for the content-length

Luca Burgazzoli

@lburgazzoli

yes it sets it according to what camel-k find on the cluster and that is expected because the name you put in the URI is used to look up the endpoint to call

you can't override it otherwise you'll have discrepancy so if you want full control, then go for the http component

Nicola Ferraro

@nicolaferraro

the point is: if you want to send data to knative:endpoint/myservice, why would you put into the Host header something different than hostname of the myservice kservice?

Luca Morandini

@lmorandini

Because I was not able to make the former work, hence I tried the latter, but then the host header is overwritten and that option fails as well.

Luca Morandini

@lmorandini

With the "knative:"protocol the issue seems to be related to the DNS

at io.netty.resolver.dns.DnsQueryContext.finish(DnsQueryContext.java:196) [io.netty.netty-resolver-dns-4.1.39.Final.jar:4.1.39.Final]
[1]     at io.netty.resolver.dns.DnsNameResolver$DnsResponseHandler.channelRead(DnsNameResolver.java:1296) [io.netty.netty-resolver-dns-4.1.39.Final.jar:4.1.39.Final]

WARN  [vert.x-eventloop-thread-1] TimerConsumer - Error processing exchange. Exchange[ID-integration-697698cb97-vrvnd-1572430131242-0-41]. Caused by: [org.apache.camel.CamelException - HTTP operation failed invoking http://echo-nodejs.phrasal-datum-256003.svc.cluster.local:80/]
[1] org.apache.camel.CamelException: HTTP operation failed invoking http://echo-nodejs.phrasal-datum-256003.svc.cluster.local:80/
[1]     at org.apache.camel.component.knative.http.KnativeHttpProducer.lambda$process$0(KnativeHttpProducer.java:156) ~[org.apache.camel.k.camel-knative-http-1.0.6.jar:1.0.6]

Luca Morandini

@lmorandini

I re-tried with a fresh install: Istio 1.3.3, Knative 0.9.0, and Camel-K 1.0.0-M3-SNAPSHOT

Calling a service with knative://endpoint/echo-nodejs results in "error during trait customization: cannot find endpoint echo-nodejs" during deployment
Calling a service with http://echo-nodejs.phrasal-datum-256003.103.6.252.48.xip.io results in a successful deployment but a 502 (after a while) once called

(The Knative service works when called from outside of Camel-K.)

elakito

@elakito

I am trying to run the tutorial sample on OSX Docker Desktop (2.1.0.4) with local repository http://localhost:5000.
When I run kamel run hello.groovy both camel-k-kit-bn9ccb8lrn3r295u9q40-builder and camel-k-kit-bn9ccb8lrn3r295u9q40 end with Terminated: Error and in the log of camel-k-kit-bn9ccb8lrn3r295u9q40, I see error pushing image: getting tag for destination: repository can only contain the runesabcdefghijklmnopqrstuvwxyz0123456789_-./: /localhost:5000/default/camel-k-kit-bn9ccb8lrn3r295u9q40. Could someone tell me what this means?

Andrea Tarocchi

@valdar

it seems it does not like some character in the name of the tag

even though they seems al char in the specified allowed set (i.e. abcdefghijklmnopqrstuvwxyz0123456789_-./)

pablo portillo

@pabloxtiyo

Hi Guys, do you know how to change/modify the service that camel k creates by default from ClusterIp to LoadBalancer?

im running this command:: kamel run StackDriverWebHookRoute.java --depende
ncy=camel-rest --dependency=camel-restlet -n arch--dev

but service is always a ClusterIp

Luca Burgazzoli

@lburgazzoli

@pabloxtiyo I think we do not have such option now, do you mind opening an issue?

pablo portillo

@pabloxtiyo

great! thanks Luca

elakito

@elakito

part of my problem (my post above) that I had was that I was using --registry with the unresolvable localhost:5000. I changed it to --registry=host.docker.internal:5000/repo and pod camel-k-kit-bnbs4q1ivl6qipbs84c0 successfully pushed image default/camel-k-kit-bnbs4q1ivl6qipbs84c0:113106 but pod hello-74f5579bb7-5msmg fails with

Failed to pull image "host.docker.internal:5000/repo/default/camel-k-kit-bnbs4q1ivl6qipbs84c0:113106": rpc error: code = Unknown desc = Error response from daemon: Get https://host.docker.internal:5000/v2/: http: server gave HTTP response to HTTPS client

. My question is why the pull triggered from this pod is using https instead of http because pod camel-k-kit-bnbs4q1ivl6qipbs84c0 used http. Do I configure or use a different setting?

elakito

@elakito

another stupid mistake of me that I forgot to add that address to the insecure registry list in my docker desktop. now it is running.

Andrea Tarocchi

@valdar

cool!

athishsreeram

@athishsreeram

https://github.com/abouchama/CamelK-customerAPI.git

In minikube

➜ route git:(master) ✗ kamel run Customer.java --dev
--name customers
--dependency camel-undertow
--dependency camel-rest
--property camel.rest.port=8080
integration "customers" updated

text_fields timer_off refresh exposure_zero file_download INFO[0000] Downloading base image 10.105.185.86/default/camel-k-kit-bnbm3p7kqcn52k5g91l0:57989 2019/11/23 07:05:28 No matching credentials were found, falling back on anonymous INFO[0000] Error while retrieving image from cache: MANIFEST_UNKNOWN: "manifest unknown" INFO[0000] Downloading base image 10.105.185.86/default/camel-k-kit-bnbm3p7kqcn52k5g91l0:57989 2019/11/23 07:05:28 No matching credentials were found, falling back on anonymous error building image: getting stage builder for stage 0: MANIFEST_UNKNOWN: "manifest unknown

apache/camel-k#1080

Luca Burgazzoli

@lburgazzoli

seems an issue with the registry

can you check if the required images exists ?

Claus Ibsen

@davsclaus

@athishsreeram got that MANIFEST error too once, i restarted minikube and/or also reset kamel k

one issue i had that caused this was my namespace was memory limited per pod, so the builder pod ran OOME and this caused following builds to still fail, when i lifted the memory limit

Where communities thrive

People

Repo info

Activity