Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    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
    image.png
    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

    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