Thanks Pasquale,
I personally think everything related to Kamelets should be on Camel-Kamelets
repository.
So I would move it there.
Are there any relationship with the website and the CRDs? Do we need to modify
something in terms of docs?
Thanks.
--Andrea Cosentino ----------------------------------Apache Camel PMC
ChairApache Karaf CommitterApache Servicemix PMC MemberEmail:
ancosen1985@yahoo.comTwitter: @oscerd2Github: oscerd
On Wednesday, September 18, 2024 at 03:17:12 PM GMT+2, Pasquale Congiusti
<pasquale.congiu...@gmail.com> wrote:
Hello again.
Since we did not yet reach an agreement on where to have the CRD spec, I've
made a draft PR to show what exactly is the code we'll be required to
manage [1]. We can decide to keep it where it is, on Kamelets catalog
project or either move to Camel or a brand new subproject. If we keep it
where it is, mind that there is a circular dependency reference between
Camel-Kamelets and Camel core (mainly due to JBang).
Maybe it would make sense to move Camel JBang off the core as Otavio is
advocating, in order to have a clean chain of dependencies, ie, Camel >
Camel-Kamelets > Camel JBang (but I guess this would be a separate thread
and work stream).
Cheers,
Pasquale.
[1] https://github.com/apache/camel-kamelets/pull/2203
On Tue, Sep 10, 2024 at 11:27 AM Pasquale Congiusti <
pasquale.congiu...@gmail.com> wrote:
> Hello,
> replies inline.
>
> On Tue, Sep 10, 2024 at 9:14 AM Christoph Deppisch
> <cfrea...@googlemail.com.invalid> wrote:
>
>> > 1. Move the spec into another separate project
>> I think you wrote that the Java CRD model is not part of this new
>> sub-project. Why is this? Can't we just also have this as a Java artifact
>> as part of the sub-project, too? On the downside having a sub-project
>> creates yet another release lifecycle with yet another versioning that
>> users need to keep in sync. But the CRD has been quite stable in the past
>> so there is not many breaking changes and releases expected I guess.
>>
>>
> The problem is the release versioning scheme. Kubernetes CRDs have adopted
> a different approach from the semantic version which is the one required to
> release Maven CRD artifacts. Basically, although we have a v1 in Kubernetes
> CRD, we can introduce non breaking compatibility changes in the same
> version. However, if we want to release a new Maven artifact we must bump
> at least the patch version number (ie, 1.0.1). We may introduce such
> dependency in the new module, but it would require to be aligned with the
> Camel versioning and be released accordingly at each release as well. If we
> have this into the Kamelet Catalog or the core, we will reuse the same
> release instead.
>
>
>> > 2. Move the spec into Kamelets
>> I think we are also talking about CRDs that are not related to Kamelets
>> (e.g. Integration), right? I think for some of the CRDs the Kamelet
>> catalog
>> is not a natural fit
>>
>>
> No, I was only planning to move Kamelets CRD.
>
>
>> > 3. Move the spec to the core
>> If this move includes the CRDs itself (not only the Java model) I think
>> this move would not be a good solution because Camel K would need to wait
>> for a new Camel release to be able to change its own operator CRDs and
>> this
>> feels very weird IMO (the same applies for solution #2). Also the
>> auto-generation tooling for CRDs is quite operator specific and might not
>> fit well into a Java based project like Camel core.
>>
>>
> No, it would not be a problem. The release cadence of CRD specification
> must be independent from the core release cadence. This is particularly
> valid as we're talking about a stable version and we do expect no breaking
> compatibility changes, if any. You may be confused with the release of the
> Maven dependency (which is just a tool). Each project can and should use
> the CRD according to its own specific requirements. Camel K would copy the
> Kamelet CRD specification from the latest stable and it won't depend on the
> Maven tool.
>
>
>> Overall I must say there is no solution that just fits altogether but
>> solution #1 seems to be the best option IMO. As mentioned I would try to
>> also include the Java CRD model into the separate project, too. The
>> question is if we gain much of a relief with that compared to #4 that just
>> keeps the status quo
>>
>>
>> Am Fr., 6. Sept. 2024 um 14:46 Uhr schrieb Pasquale Congiusti <
>> pasquale.congiu...@gmail.com>:
>>
>> > Thanks Otavio,
>> >
>> > On Fri, Sep 6, 2024 at 2:17 PM Otavio Rodolfo Piske <
>> angusyo...@gmail.com>
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > I understand the motivations for the change and, as I have expressed
>> in a
>> > > few discussions in the past, I am a strong -1 with this change.
>> > >
>> > > Personally I feel that Camel Core is already far too big ... to the
>> point
>> > > that affects our ability to have a code base that is clean, well
>> > designed,
>> > > well performing and elegant. We already suffer with a lot of code
>> > > duplication and low cohesion in the core project and already struggle
>> to
>> > > maintain reasonably decent stability for our tests.
>> > >
>> > >
>> > I understand your concert and I agree about the complex managment of the
>> > core, as mentioned in my previous email. That was the reason why I was
>> > advocating to have the spec into the Kamelet catalog subproject, which
>> is
>> > where it seems most natural fit.
>> >
>> > The real solution should be probably to have yet another subproject
>> only to
>> > manage the CRDs, because this is an API spec widely used by different
>> > components: Camel K (which is the one using its Kubernetes features),
>> core
>> > Camel, Kamelets, JBang and in theory, any other external tool out there
>> > (I'm thinking for instance to UI such as Kaoto, Karavan and other new
>> > projects such as Knative which are experimenting directly with
>> Kamelets).
>> > This project would only maintain the specification, without requiring
>> any
>> > particular release process (just tag according the supported versions,
>> so
>> > far v1 and soon to be removed v1Alpha1). The downside with this approach
>> > would be that we would not have a java CRD dependency, or, this one
>> should
>> > be maintained into Kamelet catalog subproject. This is mainly used for
>> > tooling in Java (Jbang, UIs, etc).
>> >
>> >
>> > > Although I understand we are talking about CRDs and that is not "code
>> per
>> > > se", I am particularly concerned with the growth of complexity of the
>> > core
>> > > project. Specially in terms of build time dependencies between
>> modules. I
>> > > would *hate* to go back those early 3.x days, when a build of Camel
>> would
>> > > take several minutes to complete (even though 4.x is much better, we
>> > still
>> > > have work to do [1] [2]).
>> > >
>> > >
>> > Technically speaking there would be no compilation, as I think we should
>> > just maintain some tool to autogenerate the spec as it happens now in
>> Camel
>> > K. However, it would be yet another little drop into the already complex
>> > project management if we add into the core.
>> >
>> >
>> > > Instead, what I truly would like to see is us promoting Camel JBang
>> as a
>> > > sub-project (either as a sub-project in its own or as a part of a
>> > > tooling-focused sub-project) [3] and then moving these CRDs there.
>> > >
>> > > 1. https://issues.apache.org/jira/browse/CAMEL-18701
>> > > 2. https://issues.apache.org/jira/browse/CAMEL-19504
>> > > 3. https://issues.apache.org/jira/browse/CAMEL-20265
>> > >
>> > >
>> > It would not make sense either, as written above, the spec is something
>> > used among different projects.
>> >
>> > My preferred solutions at this stage would be the following:
>> >
>> > 1. Move the spec into another separate project
>> > 2. Move the spec into Kamelets
>> > 3. Move the spec to the core
>> > 4. Keep status quo
>> >
>> >
>> > > Kind regards
>> > >
>> > > On Tue, Sep 3, 2024 at 10:41 AM Pasquale Congiusti <
>> > > pasquale.congiu...@gmail.com> wrote:
>> > >
>> > > > Thanks Christoph.
>> > > >
>> > > > From Camel K perspective there won't be any "logical" problem. In
>> the
>> > > sense
>> > > > that it will copy the specification from the new source when it has
>> to
>> > > > bundle the Kamelets CRDs. As the API versioning model is different
>> from
>> > > the
>> > > > typical semantic versioning I don't expect big issues when it's
>> time to
>> > > > pick the right version (it's been stable in v1 for a while).
>> > > >
>> > > > Then as to where such a spec has to end up, I have no particular
>> > opinion.
>> > > > It felt more natural to stay as near as possible where the Kamelets
>> are
>> > > > developed (the catalog). However, it is true that the core has some
>> > > direct
>> > > > usage. My main concern in moving into the core would be to have a
>> more
>> > > > complex project management and release process. Camel core is
>> already
>> > > > difficult to handle from that perspective, so adding some more
>> > complexity
>> > > > may feel intimidating.
>> > > >
>> > > > I'll wait for some more opinion about this last point.
>> > > >
>> > > > On Tue, Sep 3, 2024 at 10:07 AM Christoph Deppisch
>> > > > <cfrea...@googlemail.com.invalid> wrote:
>> > > >
>> > > > > Hello Pasquale,
>> > > > >
>> > > > > +1 on moving the Java CRD model generation as it is a source of
>> > > circular
>> > > > > dependencies. But what about the pure CRD YAML definitions (
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/camel-k/tree/main/pkg/resources/config/crd/bases
>> > > > > )?
>> > > > > From a Camel K operator perspective wouldn't it be weird to loose
>> the
>> > > > > ownership of those resources?
>> > > > >
>> > > > > When speaking of circular dependencies we should think about
>> Kamelets
>> > > > > catalog repository, too. The utilities located in the catalog
>> > represent
>> > > > > another source of circular dependencies. Maybe it makes sense to
>> move
>> > > the
>> > > > > Java CRD model and the Kamelets into Camel:
>> > > > > https://issues.apache.org/jira/browse/CAMEL-21049
>> > > > >
>> > > > > Cheers,
>> > > > > Christoph
>> > > > >
>> > > > > Am Di., 3. Sept. 2024 um 09:25 Uhr schrieb Pasquale Congiusti <
>> > > > > pasquale.congiu...@gmail.com>:
>> > > > >
>> > > > > > Thanks Andrea,
>> > > > > > yes, there will be quite some work to do as we have many
>> circular
>> > > > > > references and other aspects which we need to move off from
>> Camel
>> > K.
>> > > > The
>> > > > > > CRDs project should be partially moved as well, as it contains
>> the
>> > > > > > dependency used by the tooling. Fortunately Kamelets should not
>> > have
>> > > > > > references on others API, but we'll discover while working on
>> it.
>> > > > > >
>> > > > > > Cheers,
>> > > > > > Pasquale.
>> > > > > >
>> > > > > > On Tue, Sep 3, 2024 at 8:15 AM Andrea Cosentino <
>> anco...@gmail.com
>> > >
>> > > > > wrote:
>> > > > > >
>> > > > > > > Hello Pasquale,
>> > > > > > >
>> > > > > > > I think it makes sense.
>> > > > > > >
>> > > > > > > This will mean moving the following project and the related
>> crds
>> > in
>> > > > > base,
>> > > > > > > right?
>> > > > > > >
>> > > > > > > https://github.com/apache/camel-k/tree/main/java/crds
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > Il giorno lun 2 set 2024 alle ore 17:18 Pasquale Congiusti <
>> > > > > > > pasquale.congiu...@gmail.com> ha scritto:
>> > > > > > >
>> > > > > > > > Hi folks,
>> > > > > > > > in the past we've discussed the opportunity to move the
>> > > > specification
>> > > > > > of
>> > > > > > > > Kamelet from Camel K to Camel since Kamelets have been a
>> > general
>> > > > > > concept
>> > > > > > > > for some time. I'd like to set the ground for a shared
>> decision
>> > > on
>> > > > > what
>> > > > > > > to
>> > > > > > > > achieve. I will create a JIRA, but, before, I'd like to
>> > > understand
>> > > > if
>> > > > > > we
>> > > > > > > > all agree with the following points.
>> > > > > > > >
>> > > > > > > > 1. We should move the CRD from Camel K to the Kamelet
>> > catalog
>> > > > > > > > repository. It's important we familiarize ourselves with
>> the
>> > > > > > > Kubernetes
>> > > > > > > > API
>> > > > > > > > management policy, above all with deprecation policy [1]
>> and
>> > > > make
>> > > > > > sure
>> > > > > > > > to
>> > > > > > > > avoid any change that would break any public clients
>> > > > > compatibility.
>> > > > > > > The
>> > > > > > > > API
>> > > > > > > > may be used by any application/tool outside Apache Camel
>> and
>> > > it
>> > > > is
>> > > > > > > > vital to
>> > > > > > > > make sure we respect the contract. Kamelets API has been
>> GA
>> > in
>> > > > v1
>> > > > > > > since
>> > > > > > > > a
>> > > > > > > > while and it's quite stable. I suggest discussing any
>> > > > non-trivial
>> > > > > > > change
>> > > > > > > > publicly in order to always understand the potential
>> impact
>> > > > > outside
>> > > > > > > the
>> > > > > > > > Apache Camel ecosystem.
>> > > > > > > > 2. We should rethink the bundling process for the
>> provided
>> > > > Kamelet
>> > > > > > > > catalog in Camel K. Above all, we need to align with the
>> > > > expected
>> > > > > > > > behavior
>> > > > > > > > provided by Camel core. The distribution model that it
>> seems
>> > > > more
>> > > > > > > > obvious
>> > > > > > > > is to leverage the catalog distributed as a dependency
>> with
>> > > > Camel
>> > > > > > > core.
>> > > > > > > > That means that, by default, the Kamelet version used for
>> > > > catalog
>> > > > > > > > provided
>> > > > > > > > Kamelet at runtime will be the one distributed with the
>> > given
>> > > > core
>> > > > > > > > version.
>> > > > > > > >
>> > > > > > > > Let me know what you people think.
>> > > > > > > >
>> > > > > > > > Thanks and regards,
>> > > > > > > > Pasquale.
>> > > > > > > >
>> > > > > > > > [1]
>> > > > >
>> https://kubernetes.io/docs/reference/using-api/deprecation-policy/
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> > >
>> > > --
>> > > Otavio R. Piske
>> > > http://orpiske.net
>> > >
>> >
>>
>
