Okey, then, we should be done. Right now I'm reorganizing docs between the different repos as well, moving the Kamelets part into the Kamelet Catalog repo, but I think we can manage as a separate PRs.
>From next release (4.9) onward we will need to communicate the CRD spec and the java CRD dependency to use for Kamelets will be the new one we'll be eventually releasing (org.apache.camel.kamelets:camel-kamelets-crds:4.9.0). I'll set Camel K to use the new spec as well. Cheers, Pasquale. On Thu, Sep 19, 2024 at 9:42 AM Andrea Cosentino <ancosen1...@yahoo.com.invalid> wrote: > 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 > >> > > > >> > > >> > > >
