fix: Adapt Knative service definition to new KnativeEnvironment definition

[astefanutti]

This PR takes into account the changes introduced in apache/camel-k-runtime#501.

It primary aims at fixing CI tests to validate other PRs.

Release Note

NONE

[astefanutti]

CamelSource controller creates CamelEnvironment with the old Host and Port fields, so this is more involved.

[lburgazzoli]

@astefanutti @nicolaferraro should we bring back the host & port on the runtime part till we change the CamelSource ?

[astefanutti]

It might be possible to do the conversion in the Knative trait. I'm exploring that approach. Even if that is temporary, I'd like to fix CI tests to validate other PRs.

[nicolaferraro]

It might be possible to do the conversion in the Knative trait. I'm exploring that approach. Even if that is temporary, I'd like to fix CI tests to validate other PRs.

Thanks, I'll change the approach for CamelSource 0.19

[astefanutti]

Now that I've got the CamelSource tests working, the TestRunBroker e2e test fails 🤕.

It seems the path part gets duplicated for some reasons:

Error:     dump.go:146:     > 2020-10-02 09:17:57,938 WARN  [org.apa.cam.com.tim.TimerConsumer] (vert.x-eventloop-thread-0) Error processing exchange. Exchange[8C338EDC8A55717-000000000000024B]. Caused by: [org.apache.camel.CamelException - HTTP operation failed invoking http://broker-ingress.knative-eventing.svc.cluster.local/test-fb340f4a-c955-4254-b03c-dbe275d467d3/default/test-fb340f4a-c955-4254-b03c-dbe275d467d3/default with statusCode: 400, statusMessage: Bad Request]: org.apache.camel.CamelException: HTTP operation failed invoking http://broker-ingress.knative-eventing.svc.cluster.local/test-fb340f4a-c955-4254-b03c-dbe275d467d3/default/test-fb340f4a-c955-4254-b03c-dbe275d467d3/default with statusCode: 400, statusMessage: Bad Request
Error:     dump.go:146:     > 	at org.apache.camel.component.knative.http.KnativeHttpProducer.lambda$process$0(KnativeHttpProducer.java:135)
Error:     dump.go:146:     > 	at io.vertx.ext.web.client.impl.HttpContext.handleDispatchResponse(HttpContext.java:313)
Error:     dump.go:146:     > 	at io.vertx.ext.web.client.impl.HttpContext.execute(HttpContext.java:300)
Error:     dump.go:146:     > 	at io.vertx.ext.web.client.impl.HttpContext.next(HttpContext.java:275)
Error:     dump.go:146:     > 	at io.vertx.ext.web.client.impl.predicate.PredicateInterceptor.handle(PredicateInterceptor.java:69)
Error:     dump.go:146:     > 	at io.vertx.ext.web.client.impl.predicate.PredicateInterceptor.handle(PredicateInterceptor.java:32)
Error:     dump.go:146:     > 	at io.vertx.ext.web.client.impl.HttpContext.next(HttpContext.java:272)
Error:     dump.go:146:     > 	at io.vertx.ext.web.client.impl.HttpContext.fire(HttpContext.java:282)
Error:     dump.go:146:     > 	at io.vertx.ext.web.client.impl.HttpContext.dispatchResponse(HttpContext.java:243)
Error:     dump.go:146:     > 	at io.vertx.ext.web.client.impl.HttpContext.lambda$null$2(HttpContext.java:373)
Error:     dump.go:146:     > 	at io.vertx.core.impl.ContextImpl.executeTask(ContextImpl.java:366)
Error:     dump.go:146:     > 	at io.vertx.core.impl.EventLoopContext.lambda$executeAsync$0(EventLoopContext.java:38)
Error:     dump.go:146:     > 	at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
Error:     dump.go:146:     > 	at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
Error:     dump.go:146:     > 	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:497)
Error:     dump.go:146:     > 	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
Error:     dump.go:146:     > 	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
Error:     dump.go:146:     > 	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
Error:     dump.go:146:     > 	at java.base/java.lang.Thread.run(Thread.java:834)

[lburgazzoli]

@astefanutti that could be related to a latest change on the runtime so if you set both the uri and path meta data, they are joined for consistency on producer and consumer side

[nicolaferraro]

So, I think there are changes in runtime that should make tests not to pass the "yaks" job.. but I see it green.
(i.e. Kamelet start and end endpoint should be renamed into "kamelet:source" and "kamelet:sink"... "direct:{{routeId}}" should no longer work).

So I've noticed that only two out of 4 dirs are executed by Yaks? Any idea why @christophd ?

[astefanutti]

@nicolaferraro @christophd YAKS call from the Knative workflow had to be changed from an all directories to an include directories with e5fdc4b#diff-8bd69437e2586424cb7447c8eed690e7R320-R321. Ideally, the monitoring tests, that can only be run on OpenShift 4, should be excluded, but it seems there is no way to exclude a particular directory from the YAKS CLI.

[astefanutti]

@lburgazzoli Thanks, must be that indeed:

{
   "services":[
      {
         "type":"event",
         "name":"default",
         "url":"http://broker-ingress.knative-eventing.svc.cluster.local/camel-k/default",
         "metadata":{
            "camel.endpoint.kind":"sink",
            "knative.apiVersion":"eventing.knative.dev/v1",
            "knative.kind":"Broker",
            "service.path":"/camel-k/default"
         }
      }
   ]
}

Does the runtime expect the URL to be path-less or should the service.path be simply removed?

[lburgazzoli]

@astefanutti no it assumes that if you provide a path, that info should be used to compute the full URI so you either provide a full uri and no service.path or you provide a base path and a relative service.path

[astefanutti]

@lburgazzoli thanks, I've removed the redundant path metadata.