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/ > > > > > > > > > >
