[I] [Discussion] Camel K roadmap 2024 [camel-k]

["squakez (via GitHub)" <gi...@apache.org>]

squakez opened a new issue, #5019:
URL: https://github.com/apache/camel-k/issues/5019

   ### Requirement
   
   Dear community, first of all, happy 2024 to all of you. As usual, in this time of the year, we want to take the opportunity to reason and discuss which should be the project goals for the year. I will start this conversation and invite everybody to include their thoughts or their desires for this year development.
   
   ## Status of 2023 roadmap
   
   Last year we dedicated a lot of effort to redesign the core of the project which ended in the new Camel K 2.0. We have mainly worked around the possibility to make the build more enterprise ready and flexible enough to eventually onboard any runtime. We managed to have a first possibility to run and import any runtime (likely available in coming Camel K 2.2). We can say that we set the track for a simpler evolution of the project in that sense.
   
   ## Area of developments for 2024
   
   We have some leftover from last year we may want to include in 2024 roadmap, above all to close the loop around a complete build experience for other runtimes. Additionally I'd like to set a main goal for this year around the possibility to **make Camel K as the technology that enables other tools in the Camel ecosystem on Kubernetes**. I'll come back on this point later. Here it follow an unsorted list of areas which I think we should deserve attention for 2024:
   
   * Expose meaningful status of Integrations for other tools to interact in a Kubernetes "native" way
   * Complete the build experience and let the user be able to build any Camel runtime
   * Remove `kamel` CLI in favour of other toolings
   * Enhance the project organization
   * Enhance quality of code
   * Discuss how to enable Kamelet versioning
   
   I'll try to add some context in words in order to ease the meaning of each point.
   
   ### Expose meaningful status of Integrations for other tools to interact in a Kubernetes "native" way
   
   This would encompass everything around the "observability" of a Camel application. Whether the application is built and run by the Camel K operator or externally we should be able to read the status and expose meaningful information in a Kubernetes "native" way. This will simplify the integration of other tools in Kubernetes which will be able to communicate via the Integration custom resource. Put in different words, any tool should be able to use the primitives available in Camel K in order to understand what's going on around a Camel application.
   
   ### Complete the build experience and let the user be able to build any Camel runtime
   
   We are just on the last mile to let this happen. We need to polish some aspect and be able to let the operator build other runtimes. At the same stage we must let the user choose how to build the application (even externally) and let the operator "operates" the Camel application.
   
   ### Remove `kamel` CLI in favour of other toolings
   
   Although it's a great utility, the `kamel` CLI is kind of limiting the development of the operator to a certain extent. We have already other initiatives ongoing which will simplify the creation of an Integration custom resource. Camel Jbang is one of them (we already started some plugin development on it).
   
   ### Enhance the project organization
   
   There are aspects of the project organization that require some attention. At this stage the main problem I see is the presence of Kamelets API definition in Camel K, whilst, it should be directly in the Kamelets catalog now that Kamelets are a Camel generic thing.
   
   ### Enhance quality of code
   
   Last year we have worked on a nice feature that will calculate the testing coverage of our project. I am not a big fan of putting gate numbers but I think that by increasing the coverage we'll definitely reduce the surface for bugs discovered by the users. We should also make more use of the unit test mocking the controllers vs e2e test as the second requires more resources to execute and delay a lot the feedback on each PR (not to say that some of them are known to be flaky).
   
   ### Discuss how to enable Kamelet versioning
   
   This is something that has not a high priority, but, during the year I'd like to kick off the discussion to get ideas around how we can have an opinionated way to have multiple version for Kamelets. We have suffered this problem in various way and I think we need to find a clear way to solve it.
   
   ### Problem
   
   a
   
   ### Proposal
   
   _No response_
   
   ### Open questions
   
   _No response_


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] [Discussion] Camel K 2024 roadmap [camel-k]

["orpiske (via GitHub)" <gi...@apache.org>]

orpiske commented on issue #5019:
URL: https://github.com/apache/camel-k/issues/5019#issuecomment-1877180746

   This looks very nice @squakez! Some comments:
   
   * Remove kamel CLI in favour of other toolings
   
   Personally, I would like to see us consolidating on the Camel JBang as the de-facto CLI tool for Camel and every other sub-project. This, of course, might add some additional complexity to Camel Core and reduce further the cohesion of the core project, so we should probably evaluate [CAMEL-20264](https://issues.apache.org/jira/browse/CAMEL-20264) as a preliminary step for that. 
   
   * Enhance quality of code
   
   If there is interest, we can also evaluate adding Camel K bits to the SonarCloud instance. It has been a trusted source of cleanup material for the [Camel Core bits](https://sonarcloud.io/project/overview?id=apache_camel) (granted: I don't know how well it works for Go, so, probably needs further investigation). 
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] [Discussion] Camel K 2024 roadmap [camel-k]

["claudio4j (via GitHub)" <gi...@apache.org>]

claudio4j commented on issue #5019:
URL: https://github.com/apache/camel-k/issues/5019#issuecomment-1883930027

   We could finish the move of camel-k-runtime to camel-quarkus, eliminating camel-k-runtime.
   Add camel-k-runtime support to camel-spring-boot, so when running `camel k run <my csb-integration.java>` just works.
   The deprecation of `kamel` and the use of `camel-jbang` will require a lot of work to change e2e and to add `camel k` specific testing.
   Allow components not defined in the camel catalog.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] [Discussion] Camel K 2024 roadmap [camel-k]

["squakez (via GitHub)" <gi...@apache.org>]

squakez closed issue #5019: [Discussion] Camel K 2024 roadmap
URL: https://github.com/apache/camel-k/issues/5019


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org