camel-k API definition and test - some questions

[Gerald Kallas <ca...@mailbox.org.INVALID>]

Hi all,

I've started to play around with camel-k. I found this

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

The first try as described war running into an error during the deployment in my OpenShift cluster. I removed the "-dependency camel-undertow" and now the API is running. Some questions so far ..
1. Do I need to define dependencies or does the camel-k operator resolve these automatically?
2. How can I see the error details when a deployment fails?
3. The API can be called from everyone. How can I secure the API (authentication/authorization)?
I'm aware that camel-k requires a lot of re-think the common camel approach. Thanks for any responses.

Best
- Gerald

Re: camel-k API definition and test - some questions

[Nicola Ferraro <ni...@gmail.com>]

Hi, responses inline.

On Sun, Nov 15, 2020 at 10:33 PM Gerald Kallas <ca...@mailbox.org.invalid>
wrote:

> Hi all,
>
> I've started to play around with camel-k. I found this
>
> https://github.com/abouchama/CamelK-customerAPI
>
> The first try as described war running into an error during the deployment
> in my OpenShift cluster. I removed the "-dependency camel-undertow" and now
> the API is running. Some questions so far ..
> 1. Do I need to define dependencies or does the camel-k operator resolve
> these automatically?
>

We've recently switched to using platform-http to deploy rest routes,
that's why you probably had issues when manually adding Undertow. In
general, the operator has some rules to detect needed dependencies and add
them automatically. You need to specify them explicitly when they're not
recognized.


> 2. How can I see the error details when a deployment fails?
>

When a deployment fails (i.e. no pod is created at all), in general you see
the error in the operator logs. So `kubectl logs -f -l
name=camel-k-operator` will display some error.


> 3. The API can be called from everyone. How can I secure the API
> (authentication/authorization)?
>

Generally these are concerns better addressed by an API manager (see e.g.
3scale). But also in Camel K we've switched to Quarkus as only runtime in
the latest version, so technically you should be able to use property-based
configuration to secure endpoints (see
https://quarkus.io/guides/security-authorization).


> I'm aware that camel-k requires a lot of re-think the common camel
> approach. Thanks for any responses.
>
> Best
> - Gerald