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