On Thu, Sep 19, 2024 at 1:34 PM Claus Ibsen <[email protected]> wrote:
> Hi > > Yes I think it should be in camel-kamelets also. > > And as I understand it then the go code is only needed for updating the > spec files, > and as such are not usually needed for maintenance of the actual kamelets. > > > Correct. As it's a stable API I expect to rarely do the regen (which is entirely controlled by a script) after altering the golang Kamelet struct. > > On Thu, Sep 19, 2024 at 9:42 AM Andrea Cosentino > <[email protected]> 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: > > [email protected]: @oscerd2Github: oscerd > > > > On Wednesday, September 18, 2024 at 03:17:12 PM GMT+2, Pasquale > > Congiusti <[email protected]> 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 < > > [email protected]> wrote: > > > > > Hello, > > > replies inline. > > > > > > On Tue, Sep 10, 2024 at 9:14 AM Christoph Deppisch > > > <[email protected]> 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 < > > >> [email protected]>: > > >> > > >> > Thanks Otavio, > > >> > > > >> > On Fri, Sep 6, 2024 at 2:17 PM Otavio Rodolfo Piske < > > >> [email protected]> > > >> > 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 < > > >> > > [email protected]> 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 > > >> > > > <[email protected]> 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 > < > > >> > > > > [email protected]>: > > >> > > > > > > >> > > > > > 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 < > > >> [email protected] > > >> > > > > >> > > > > 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 < > > >> > > > > > > [email protected]> 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 > > >> > > > > >> > > > >> > > > > > > > > > -- > Claus Ibsen > ----------------- > @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 >
