Syndesis 2.0 Camel K runtime

[Pasquale Congiusti]

Hey folks,

First of all, I apologize for the length of this thread. I'd like to discuss within the community the possibility to move forward and include Camel K as runtime of Syndesis 2.0. As Camel K have recently released it's first 1.0 version, I think we must take the opportunity and align Syndesis 2.0 version to that runtime too. The first question is if there is any objection on moving forward in that direction, or any constraint we should take in consideration. Of course, enabling Camel K is not coming for free and I'd like to provide some immediate challenges we have to tackle based on the first analysis/experiments I've carried on.

As we will deal on a daily basis with development environments, let's start with this one. Camel K 1.0 has been developed with the latest Kubernetes version support, so it won't be working on Minishift or OCP3. I mention this point as many of us (including myself) use Minishift as preferred development environment. As soon as we move towards Camel K we will have to drop it in favor of CRC, Minikube (a PR has been issued recently) or directly a OCP 4 cluster.

Camel K 1.0 stable release is based on Camel K runtime 1.3, which is based on Camel 3.3 version. At the moment we are targeting Camel 3.1.0, so, in order to have everything aligned we must make an effort to bring Syndesis to Camel 3.3 and compiling against Java 11. I am working to have an intermediate step: Camel K runtime 1.1 (latest one built against Java 8 which would be Camel K 1.0-RC2) with the actual Syndesis dependencies in order to smooth the transition to 1.3 runtime. I am not 100% sure that I will manage to stabilize that: if I don't, we can directly target Camel K 1.3 runtime.

Last feedback I can provide is about the syndesis kamel CLI utility. This is something we, as developers, will have to use to test integrations. As the CRD have changed, we will have to make the changes to the CLI as well.

I am planning to write some quickstart in order to provide the basic configuration and have Camel K as runtime integration for Syndesis 2.0, so, anybody interested in this development can jump in quickly and help with the several issues we'll find along the way.

So, resuming, the path to have a basic runtime of Camel K into Syndesis looks promising but with a few challenges, reason why we need the whole community to contribute on this (developing, raising bugs, cheering up, ...). I feel the immediate effort we need to focus is for the following points:

• Fix Camel K runtime 1.1 (I'm already on it)
• Fix syndesis kamel CLI
• Have Syndesis 2.0 compiled with java 11 [1]
• Move Syndesis 2.0 to Camel 3.3
• Move Camel K runtime to 1.3

As soon as that is done we could think to cut an official 2.0 release. But it's something we can discuss later on. Last consideration I'd like to make is about two aspects I'd like to take off the table for the time being:

1. Full support for Camel K integrations (extensions, for example)
2. Just leaving Camel K as Syndesis runtime (dropping Spring boot based one)
   

I know those are important points, but I'd like to open a new discussion as soon as the known pains mentioned above are solved.

What do you think?

Thanks for your attention,

Pasquale.

[1] https://groups.google.com/forum/#!topic/syndesis/-bnwCWgfPpg

[Maria Arias de Reyna Dominguez]

Thanks for the work, Pasquale!

Some comments inline:

On Fri, Jun 19, 2020 at 10:53 AM Pasquale Congiusti <pcon...@redhat.com> wrote:
> I am planning to write some quickstart in order to provide the basic configuration and have Camel K as runtime integration for Syndesis 2.0, so, anybody interested in this development can jump in quickly and help with the several issues we'll find along the way.

That would be awesome!

> So, resuming, the path to have a basic runtime of Camel K into Syndesis looks promising but with a few challenges, reason why we need the whole community to contribute on this (developing, raising bugs, cheering up, ...). I feel the immediate effort we need to focus is for the following points:
>
> Fix Camel K runtime 1.1 (I'm already on it)
> Fix syndesis kamel CLI
> Have Syndesis 2.0 compiled with java 11 [1]
> Move Syndesis 2.0 to Camel 3.3
> Move Camel K runtime to 1.3

I can start with the java 11 thing if no one else volunteers. I think
that's a big one and the rest of the Syndesis tasks depend on it.

It also means a big step forward on java support: we drop java 8 already.

> As soon as that is done we could think to cut an official 2.0 release. But it's something we can discuss later on.

I agree, this would be a good moment to release 2.0. Major changes,
breaking backwards compatibility and stuff.

> Last consideration I'd like to make is about two aspects I'd like to take off the table for the time being:
>
> Full support for Camel K integrations (extensions, for example)
> Just leaving Camel K as Syndesis runtime (dropping Spring boot based one)

I'm in favor of simplifying Syndesis as much as possible for easier
maintenance. Camel-K is clearly a good substitute of the other runtime
engines. It is faster and it is light weighter. Syndesis has to run on
some containerized place, so having Camel-K as a dependency is not a
bigger issue IMHO. But having to maintain more than one runtime is.

I would follow Camel-K lead. If they support something, we support it.
If they don't, we drop it. Camel-K will support everything we need in
time.

[pcon...@redhat.com]

Hey team,

just an head up to communicate we've just merged the pieces to have Camel K runtime 1.3 (and that means Camel K 1.0) on master. We should be able now to run Camel K integrations and I must admit it is a pleasure to see that they start almost immediately on Syndesis! We may need to work on some framework to allow automatic testing, the same we used to do for S2I runtime in order to properly test all scenarios.

We'll keep you posted over here, though.

Cheers,

Pasquale.

[hbr...@redhat.com]

Congrats! That's a great step forward!

Heiko