You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by GitBox <gi...@apache.org> on 2022/02/28 14:12:25 UTC
[GitHub] [camel-website] squakez opened a new pull request #795: chore: Camel K roadmap 2022
squakez opened a new pull request #795:
URL: https://github.com/apache/camel-website/pull/795
I've tried to resume what we're planning to do for Camel K in 2022.
FYI @astefanutti @nicolaferraro @lburgazzoli @oscerd @davsclaus @tadayosi @johnpoth
--
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
[GitHub] [camel-website] apupier commented on a change in pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
apupier commented on a change in pull request #795:
URL: https://github.com/apache/camel-website/pull/795#discussion_r816751833
##########
File path: content/blog/2022/03/camel-k-roadmap-2022/index.md
##########
@@ -0,0 +1,116 @@
+---
+title: "Camel K 2022 Roadmap"
+date: 2022-03-01
+draft: false
+authors: [squakez]
+categories: ["Roadmap", "Camel K"]
+preview: "A brief overview of what we've planned for 2022"
+---
+
+<sub><sup><a href='https://pngtree.com/so/Signpost'>Signpost png from pngtree.com/</a></sup></sub>
+
+During the last weeks we've been asked questions around the direction we're willing to take on the future development of **Camel K**. I think it would be good to have some blog in order to let the community understand where our efforts are going. It will be useful for every Camel K user and Camel K developer, as a guide for the future development of the project.
+
+The below list of development areas are the ones identified at the end of 2021. The order is random, we haven't identified any clear priority yet. Some of those developments are already completed (fully or partially).
+
+* Code/build (release process)
+* Installation procedure
+* API
+* CLI
+* Event Driven Architecture
+* Builder (containers, images and registry)
+* Runtime (Integration execution)
+* Observability
+* Kamelets
+
+In each section, I've tried to detail the rationale and some ideas that can be furtherly refined. There may also be reference to Github issues that are related to the requirement under discussion.
+
+DISCLAIMER: this is a wide list of desired areas we may work on. We may not be able to complete all of them for any reason, neither considered responsible for any kind of committment. The contributors must not consider this as a mandatory list of work to do, but as a suggested list of things to take in consideration when dedicating time to the project.
+
+## Code/build (release process)
+The goal we identified is to simplify and speed up the release process.
+
+* Merge Camel K runtime into Camel Quarkus
+* Multi-architecture images ([#1238](https://github.com/apache/camel-k/issues/1238))
+* Modularised build ([#2801](https://github.com/apache/camel-k/issues/2801))
+* Nightly builds ([#393](https://github.com/apache/camel-k/issues/393))
+
+We now have a chain of relationships as `Camel K >> Camel K runtime >> Camel Quarkus >> Camel`. Camel K runtime could be seen as a bootstrap of `Camel Quarkus`: this approach simplifies the overall picture and releases dependencies. We may kick off joint initiative with **Camel Quarkus** community to bring the actual **Camel K Runtime**, under the Camel Quarkus umbrella.
+Through multi architecture images we will be able to widen our target audience by extending the presence of the **Operator** on different architectures. Nightly build will also let everybody use partial fixes before any official release cycle.
+
+## Installation procedure
+We have several installation process options in place. We may need to harmonize them to simplify the maintenance of the installation procedure.
+
+* Document the usage of Kustomize ([#2758](https://github.com/apache/camel-k/issues/2758))
+* Deprecate kamel install in favor of kubectl apply -k / kustomize
+* Move to descoped OLM model
+
+There is some preliminary work introduced in release 1.7 around [Kustomize](https://github.com/apache/camel-k/releases/tag/v1.7.0). We may leverage that in order to identify a replacement for the kamel install. We should analyze how that will happen and the user experience around any new way we’ll propose to the community.
+Another thread we should follow is related to the proposal about descoped OLM. This part should be put in a wider context around the OLM project.
+
+## API
+We can start thinking of Camel K as an enablement technology. Then, it makes sense to dedicate some effort in improving the way the technology may be consumed by others. APIs and CRDs are the main scope of this section.
+
+* Provide a full description of the APIs
+* Comprehensive CRD structural schemas for tooling
+* Traits configuration schema ([#1614](https://github.com/apache/camel-k/issues/1614))
+
+Implementation of structural schema may be the goal of 2.0 as will probably require many breaking changes. Some draft was realized and it provided discussions we may take in consideration during the feature implementation (see [#2831](https://github.com/apache/camel-k/issues/2831)
+
+## CLI
+The CLI is still a very useful tool when interacting with connected environments, in particular in the community.
+
+* Fill the gaps for kamel local commands
Review comment:
```suggestion
* Fill the gaps for `kamel local` commands
```
--
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
[GitHub] [camel-website] apupier commented on a change in pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
apupier commented on a change in pull request #795:
URL: https://github.com/apache/camel-website/pull/795#discussion_r816751555
##########
File path: content/blog/2022/03/camel-k-roadmap-2022/index.md
##########
@@ -0,0 +1,116 @@
+---
+title: "Camel K 2022 Roadmap"
+date: 2022-03-01
+draft: false
+authors: [squakez]
+categories: ["Roadmap", "Camel K"]
+preview: "A brief overview of what we've planned for 2022"
+---
+
+<sub><sup><a href='https://pngtree.com/so/Signpost'>Signpost png from pngtree.com/</a></sup></sub>
+
+During the last weeks we've been asked questions around the direction we're willing to take on the future development of **Camel K**. I think it would be good to have some blog in order to let the community understand where our efforts are going. It will be useful for every Camel K user and Camel K developer, as a guide for the future development of the project.
+
+The below list of development areas are the ones identified at the end of 2021. The order is random, we haven't identified any clear priority yet. Some of those developments are already completed (fully or partially).
+
+* Code/build (release process)
+* Installation procedure
+* API
+* CLI
+* Event Driven Architecture
+* Builder (containers, images and registry)
+* Runtime (Integration execution)
+* Observability
+* Kamelets
+
+In each section, I've tried to detail the rationale and some ideas that can be furtherly refined. There may also be reference to Github issues that are related to the requirement under discussion.
+
+DISCLAIMER: this is a wide list of desired areas we may work on. We may not be able to complete all of them for any reason, neither considered responsible for any kind of committment. The contributors must not consider this as a mandatory list of work to do, but as a suggested list of things to take in consideration when dedicating time to the project.
+
+## Code/build (release process)
+The goal we identified is to simplify and speed up the release process.
+
+* Merge Camel K runtime into Camel Quarkus
+* Multi-architecture images ([#1238](https://github.com/apache/camel-k/issues/1238))
+* Modularised build ([#2801](https://github.com/apache/camel-k/issues/2801))
+* Nightly builds ([#393](https://github.com/apache/camel-k/issues/393))
+
+We now have a chain of relationships as `Camel K >> Camel K runtime >> Camel Quarkus >> Camel`. Camel K runtime could be seen as a bootstrap of `Camel Quarkus`: this approach simplifies the overall picture and releases dependencies. We may kick off joint initiative with **Camel Quarkus** community to bring the actual **Camel K Runtime**, under the Camel Quarkus umbrella.
+Through multi architecture images we will be able to widen our target audience by extending the presence of the **Operator** on different architectures. Nightly build will also let everybody use partial fixes before any official release cycle.
+
+## Installation procedure
+We have several installation process options in place. We may need to harmonize them to simplify the maintenance of the installation procedure.
+
+* Document the usage of Kustomize ([#2758](https://github.com/apache/camel-k/issues/2758))
+* Deprecate kamel install in favor of kubectl apply -k / kustomize
+* Move to descoped OLM model
+
+There is some preliminary work introduced in release 1.7 around [Kustomize](https://github.com/apache/camel-k/releases/tag/v1.7.0). We may leverage that in order to identify a replacement for the kamel install. We should analyze how that will happen and the user experience around any new way we’ll propose to the community.
+Another thread we should follow is related to the proposal about descoped OLM. This part should be put in a wider context around the OLM project.
+
+## API
+We can start thinking of Camel K as an enablement technology. Then, it makes sense to dedicate some effort in improving the way the technology may be consumed by others. APIs and CRDs are the main scope of this section.
+
+* Provide a full description of the APIs
+* Comprehensive CRD structural schemas for tooling
+* Traits configuration schema ([#1614](https://github.com/apache/camel-k/issues/1614))
+
+Implementation of structural schema may be the goal of 2.0 as will probably require many breaking changes. Some draft was realized and it provided discussions we may take in consideration during the feature implementation (see [#2831](https://github.com/apache/camel-k/issues/2831)
+
+## CLI
+The CLI is still a very useful tool when interacting with connected environments, in particular in the community.
+
+* Fill the gaps for kamel local commands
+* Enable JBang
+* Better auto-completion ([#2461](https://github.com/apache/camel-k/issues/2461))
+
+We have many requests to enhance the `kamel local` command in order to perform more actions. It seems this is used in order to test the Integrations, like a development environment. We may also investigate how to leverage **JBang** as it seems a better approach for local testing. As long as the development of JBang on Camel gather maturity, we will probably address the required changes to have it better integrated in Camel K.
+
+## Event Driven Architecture
+We can think of Camel K as a technology to be used in **Kubernetes** space for event driven architectures. For this reason we will work to enable certain aspects required by EDA.
+
+* Offset management
+* Source partitioning and load balancing
+* Integration with Keda auto-scalers
+* Knative stability
+* Kamelets support/stability
+
+Following the strategy of the EDA positioning, we should focus on creating a stable environment for **Knative**, **Kamelets** and **Kafka**. In the same direction we must explore the **Keda** ecosystem and how the first implementation fits into Camel K model.
+
+## Builder
+Integration building process needs to be tweaked in order to guarantee scalability. We may revisit parts of the process in order to be more “production grade”.
+
+* Improve concurrency / scalability ([#1784](https://github.com/apache/camel-k/issues/1784))
+* Image garbage collection / compaction ([#2736](https://github.com/apache/camel-k/issues/2736))
+* Support OCI registries for universal artifacts management ([#2732](https://github.com/apache/camel-k/issues/2732))
Review comment:
```suggestion
* Support Open Container Initiative ([OCI](https://opencontainers.org/)) registries for universal artifacts management ([#2732](https://github.com/apache/camel-k/issues/2732))
```
--
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
[GitHub] [camel-website] apupier commented on a change in pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
apupier commented on a change in pull request #795:
URL: https://github.com/apache/camel-website/pull/795#discussion_r816754845
##########
File path: content/blog/2022/03/camel-k-roadmap-2022/index.md
##########
@@ -0,0 +1,116 @@
+---
+title: "Camel K 2022 Roadmap"
+date: 2022-03-01
+draft: false
+authors: [squakez]
+categories: ["Roadmap", "Camel K"]
+preview: "A brief overview of what we've planned for 2022"
+---
+
+<sub><sup><a href='https://pngtree.com/so/Signpost'>Signpost png from pngtree.com/</a></sup></sub>
+
+During the last weeks we've been asked questions around the direction we're willing to take on the future development of **Camel K**. I think it would be good to have some blog in order to let the community understand where our efforts are going. It will be useful for every Camel K user and Camel K developer, as a guide for the future development of the project.
+
+The below list of development areas are the ones identified at the end of 2021. The order is random, we haven't identified any clear priority yet. Some of those developments are already completed (fully or partially).
+
+* Code/build (release process)
+* Installation procedure
+* API
+* CLI
+* Event Driven Architecture
+* Builder (containers, images and registry)
+* Runtime (Integration execution)
+* Observability
+* Kamelets
+
+In each section, I've tried to detail the rationale and some ideas that can be furtherly refined. There may also be reference to Github issues that are related to the requirement under discussion.
+
+DISCLAIMER: this is a wide list of desired areas we may work on. We may not be able to complete all of them for any reason, neither considered responsible for any kind of committment. The contributors must not consider this as a mandatory list of work to do, but as a suggested list of things to take in consideration when dedicating time to the project.
+
+## Code/build (release process)
+The goal we identified is to simplify and speed up the release process.
+
+* Merge Camel K runtime into Camel Quarkus
+* Multi-architecture images ([#1238](https://github.com/apache/camel-k/issues/1238))
+* Modularised build ([#2801](https://github.com/apache/camel-k/issues/2801))
+* Nightly builds ([#393](https://github.com/apache/camel-k/issues/393))
+
+We now have a chain of relationships as `Camel K >> Camel K runtime >> Camel Quarkus >> Camel`. Camel K runtime could be seen as a bootstrap of `Camel Quarkus`: this approach simplifies the overall picture and releases dependencies. We may kick off joint initiative with **Camel Quarkus** community to bring the actual **Camel K Runtime**, under the Camel Quarkus umbrella.
+Through multi architecture images we will be able to widen our target audience by extending the presence of the **Operator** on different architectures. Nightly build will also let everybody use partial fixes before any official release cycle.
+
+## Installation procedure
+We have several installation process options in place. We may need to harmonize them to simplify the maintenance of the installation procedure.
+
+* Document the usage of Kustomize ([#2758](https://github.com/apache/camel-k/issues/2758))
+* Deprecate kamel install in favor of kubectl apply -k / kustomize
+* Move to descoped OLM model
Review comment:
```suggestion
* Move to descoped Operator Lifecycle Manager [OLM](https://docs.openshift.com/container-platform/4.9/operators/understanding/olm/olm-understanding-olm.html) model
```
--
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
[GitHub] [camel-website] apupier commented on a change in pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
apupier commented on a change in pull request #795:
URL: https://github.com/apache/camel-website/pull/795#discussion_r816753872
##########
File path: content/blog/2022/03/camel-k-roadmap-2022/index.md
##########
@@ -0,0 +1,116 @@
+---
+title: "Camel K 2022 Roadmap"
+date: 2022-03-01
+draft: false
+authors: [squakez]
+categories: ["Roadmap", "Camel K"]
+preview: "A brief overview of what we've planned for 2022"
+---
+
+<sub><sup><a href='https://pngtree.com/so/Signpost'>Signpost png from pngtree.com/</a></sup></sub>
+
+During the last weeks we've been asked questions around the direction we're willing to take on the future development of **Camel K**. I think it would be good to have some blog in order to let the community understand where our efforts are going. It will be useful for every Camel K user and Camel K developer, as a guide for the future development of the project.
+
+The below list of development areas are the ones identified at the end of 2021. The order is random, we haven't identified any clear priority yet. Some of those developments are already completed (fully or partially).
+
+* Code/build (release process)
+* Installation procedure
+* API
+* CLI
+* Event Driven Architecture
+* Builder (containers, images and registry)
+* Runtime (Integration execution)
+* Observability
+* Kamelets
+
+In each section, I've tried to detail the rationale and some ideas that can be furtherly refined. There may also be reference to Github issues that are related to the requirement under discussion.
+
+DISCLAIMER: this is a wide list of desired areas we may work on. We may not be able to complete all of them for any reason, neither considered responsible for any kind of committment. The contributors must not consider this as a mandatory list of work to do, but as a suggested list of things to take in consideration when dedicating time to the project.
+
+## Code/build (release process)
+The goal we identified is to simplify and speed up the release process.
+
+* Merge Camel K runtime into Camel Quarkus
+* Multi-architecture images ([#1238](https://github.com/apache/camel-k/issues/1238))
+* Modularised build ([#2801](https://github.com/apache/camel-k/issues/2801))
+* Nightly builds ([#393](https://github.com/apache/camel-k/issues/393))
+
+We now have a chain of relationships as `Camel K >> Camel K runtime >> Camel Quarkus >> Camel`. Camel K runtime could be seen as a bootstrap of `Camel Quarkus`: this approach simplifies the overall picture and releases dependencies. We may kick off joint initiative with **Camel Quarkus** community to bring the actual **Camel K Runtime**, under the Camel Quarkus umbrella.
+Through multi architecture images we will be able to widen our target audience by extending the presence of the **Operator** on different architectures. Nightly build will also let everybody use partial fixes before any official release cycle.
+
+## Installation procedure
+We have several installation process options in place. We may need to harmonize them to simplify the maintenance of the installation procedure.
+
+* Document the usage of Kustomize ([#2758](https://github.com/apache/camel-k/issues/2758))
+* Deprecate kamel install in favor of kubectl apply -k / kustomize
Review comment:
```suggestion
* Deprecate `kamel install` in favor of `kubectl apply -k` / `kustomize`
```
--
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
[GitHub] [camel-website] apupier commented on a change in pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
apupier commented on a change in pull request #795:
URL: https://github.com/apache/camel-website/pull/795#discussion_r816749898
##########
File path: content/blog/2022/03/camel-k-roadmap-2022/index.md
##########
@@ -0,0 +1,116 @@
+---
+title: "Camel K 2022 Roadmap"
+date: 2022-03-01
+draft: false
+authors: [squakez]
+categories: ["Roadmap", "Camel K"]
+preview: "A brief overview of what we've planned for 2022"
+---
+
+<sub><sup><a href='https://pngtree.com/so/Signpost'>Signpost png from pngtree.com/</a></sup></sub>
+
+During the last weeks we've been asked questions around the direction we're willing to take on the future development of **Camel K**. I think it would be good to have some blog in order to let the community understand where our efforts are going. It will be useful for every Camel K user and Camel K developer, as a guide for the future development of the project.
+
+The below list of development areas are the ones identified at the end of 2021. The order is random, we haven't identified any clear priority yet. Some of those developments are already completed (fully or partially).
+
+* Code/build (release process)
+* Installation procedure
+* API
+* CLI
+* Event Driven Architecture
+* Builder (containers, images and registry)
+* Runtime (Integration execution)
+* Observability
+* Kamelets
+
+In each section, I've tried to detail the rationale and some ideas that can be furtherly refined. There may also be reference to Github issues that are related to the requirement under discussion.
+
+DISCLAIMER: this is a wide list of desired areas we may work on. We may not be able to complete all of them for any reason, neither considered responsible for any kind of committment. The contributors must not consider this as a mandatory list of work to do, but as a suggested list of things to take in consideration when dedicating time to the project.
+
+## Code/build (release process)
+The goal we identified is to simplify and speed up the release process.
+
+* Merge Camel K runtime into Camel Quarkus
+* Multi-architecture images ([#1238](https://github.com/apache/camel-k/issues/1238))
+* Modularised build ([#2801](https://github.com/apache/camel-k/issues/2801))
+* Nightly builds ([#393](https://github.com/apache/camel-k/issues/393))
+
+We now have a chain of relationships as `Camel K >> Camel K runtime >> Camel Quarkus >> Camel`. Camel K runtime could be seen as a bootstrap of `Camel Quarkus`: this approach simplifies the overall picture and releases dependencies. We may kick off joint initiative with **Camel Quarkus** community to bring the actual **Camel K Runtime**, under the Camel Quarkus umbrella.
+Through multi architecture images we will be able to widen our target audience by extending the presence of the **Operator** on different architectures. Nightly build will also let everybody use partial fixes before any official release cycle.
+
+## Installation procedure
+We have several installation process options in place. We may need to harmonize them to simplify the maintenance of the installation procedure.
+
+* Document the usage of Kustomize ([#2758](https://github.com/apache/camel-k/issues/2758))
+* Deprecate kamel install in favor of kubectl apply -k / kustomize
+* Move to descoped OLM model
+
+There is some preliminary work introduced in release 1.7 around [Kustomize](https://github.com/apache/camel-k/releases/tag/v1.7.0). We may leverage that in order to identify a replacement for the kamel install. We should analyze how that will happen and the user experience around any new way we’ll propose to the community.
+Another thread we should follow is related to the proposal about descoped OLM. This part should be put in a wider context around the OLM project.
+
+## API
+We can start thinking of Camel K as an enablement technology. Then, it makes sense to dedicate some effort in improving the way the technology may be consumed by others. APIs and CRDs are the main scope of this section.
+
+* Provide a full description of the APIs
+* Comprehensive CRD structural schemas for tooling
+* Traits configuration schema ([#1614](https://github.com/apache/camel-k/issues/1614))
+
+Implementation of structural schema may be the goal of 2.0 as will probably require many breaking changes. Some draft was realized and it provided discussions we may take in consideration during the feature implementation (see [#2831](https://github.com/apache/camel-k/issues/2831)
+
+## CLI
+The CLI is still a very useful tool when interacting with connected environments, in particular in the community.
+
+* Fill the gaps for kamel local commands
+* Enable JBang
+* Better auto-completion ([#2461](https://github.com/apache/camel-k/issues/2461))
+
+We have many requests to enhance the `kamel local` command in order to perform more actions. It seems this is used in order to test the Integrations, like a development environment. We may also investigate how to leverage **JBang** as it seems a better approach for local testing. As long as the development of JBang on Camel gather maturity, we will probably address the required changes to have it better integrated in Camel K.
+
+## Event Driven Architecture
+We can think of Camel K as a technology to be used in **Kubernetes** space for event driven architectures. For this reason we will work to enable certain aspects required by EDA.
+
+* Offset management
+* Source partitioning and load balancing
+* Integration with Keda auto-scalers
+* Knative stability
+* Kamelets support/stability
+
+Following the strategy of the EDA positioning, we should focus on creating a stable environment for **Knative**, **Kamelets** and **Kafka**. In the same direction we must explore the **Keda** ecosystem and how the first implementation fits into Camel K model.
+
+## Builder
+Integration building process needs to be tweaked in order to guarantee scalability. We may revisit parts of the process in order to be more “production grade”.
+
+* Improve concurrency / scalability ([#1784](https://github.com/apache/camel-k/issues/1784))
+* Image garbage collection / compaction ([#2736](https://github.com/apache/camel-k/issues/2736))
+* Support OCI registries for universal artifacts management ([#2732](https://github.com/apache/camel-k/issues/2732))
+* CI/CD support
+* Build Pod compute resources
+
+**[Mvnd](https://github.com/apache/maven-mvnd)** is a good candidate for improving the scalability of the builds. Some preliminary work already exists (see [#2832](https://github.com/apache/camel-k/issues/2832)). Some interesting work is already in place to provide layered images for dependencies (see [#2835](https://github.com/apache/camel-k/issues/2835)). There is certain demand for reducing the quantity of debris produced during the creation of images (ie, garbage collection) and to show how to integrate Camel K with some CI/CD tool.
+
+## Runtime
+Other efforts that will let Camel K be more mature are related to features around the runtime.
+
+* Improve route DSL parsing ([#1266](https://github.com/apache/camel-k/issues/1266))
+* Surface Camel health checks into integration status ([#2886](https://github.com/apache/camel-k/issues/2886)
+* Business vs. technical errors
+
+Route parsing has a great margin of improvement in order to automatically discover components, capabilities, dependencies, etc, and in general to be more reliable. Also, exposing more meaningful ways to query the healthy status of an Integration will let users speed up their troubleshooting (this part is almost completed in the latest releases).
+
+## Observability
+Monitoring running Integrations is another field which will let the user feel the maturity of the product.
+
+* Migrate from MicroProfile metrics to Micrometer
+* Secured monitoring (see proposal)
+* Grafana dashboards
Review comment:
```suggestion
* [Grafana](https://grafana.com/) dashboards
```
--
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
[GitHub] [camel-website] github-actions[bot] commented on pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
github-actions[bot] commented on pull request #795:
URL: https://github.com/apache/camel-website/pull/795#issuecomment-1055429558
🚀 Preview is available at https://pr-795--camel.netlify.app
--
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
[GitHub] [camel-website] apupier commented on a change in pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
apupier commented on a change in pull request #795:
URL: https://github.com/apache/camel-website/pull/795#discussion_r816746794
##########
File path: content/blog/2022/03/camel-k-roadmap-2022/index.md
##########
@@ -0,0 +1,116 @@
+---
+title: "Camel K 2022 Roadmap"
+date: 2022-03-01
+draft: false
+authors: [squakez]
+categories: ["Roadmap", "Camel K"]
+preview: "A brief overview of what we've planned for 2022"
+---
+
+<sub><sup><a href='https://pngtree.com/so/Signpost'>Signpost png from pngtree.com/</a></sup></sub>
+
+During the last weeks we've been asked questions around the direction we're willing to take on the future development of **Camel K**. I think it would be good to have some blog in order to let the community understand where our efforts are going. It will be useful for every Camel K user and Camel K developer, as a guide for the future development of the project.
+
+The below list of development areas are the ones identified at the end of 2021. The order is random, we haven't identified any clear priority yet. Some of those developments are already completed (fully or partially).
+
+* Code/build (release process)
+* Installation procedure
+* API
+* CLI
+* Event Driven Architecture
+* Builder (containers, images and registry)
+* Runtime (Integration execution)
+* Observability
+* Kamelets
+
+In each section, I've tried to detail the rationale and some ideas that can be furtherly refined. There may also be reference to Github issues that are related to the requirement under discussion.
+
+DISCLAIMER: this is a wide list of desired areas we may work on. We may not be able to complete all of them for any reason, neither considered responsible for any kind of committment. The contributors must not consider this as a mandatory list of work to do, but as a suggested list of things to take in consideration when dedicating time to the project.
+
+## Code/build (release process)
+The goal we identified is to simplify and speed up the release process.
+
+* Merge Camel K runtime into Camel Quarkus
+* Multi-architecture images ([#1238](https://github.com/apache/camel-k/issues/1238))
+* Modularised build ([#2801](https://github.com/apache/camel-k/issues/2801))
+* Nightly builds ([#393](https://github.com/apache/camel-k/issues/393))
+
+We now have a chain of relationships as `Camel K >> Camel K runtime >> Camel Quarkus >> Camel`. Camel K runtime could be seen as a bootstrap of `Camel Quarkus`: this approach simplifies the overall picture and releases dependencies. We may kick off joint initiative with **Camel Quarkus** community to bring the actual **Camel K Runtime**, under the Camel Quarkus umbrella.
+Through multi architecture images we will be able to widen our target audience by extending the presence of the **Operator** on different architectures. Nightly build will also let everybody use partial fixes before any official release cycle.
+
+## Installation procedure
+We have several installation process options in place. We may need to harmonize them to simplify the maintenance of the installation procedure.
+
+* Document the usage of Kustomize ([#2758](https://github.com/apache/camel-k/issues/2758))
+* Deprecate kamel install in favor of kubectl apply -k / kustomize
+* Move to descoped OLM model
+
+There is some preliminary work introduced in release 1.7 around [Kustomize](https://github.com/apache/camel-k/releases/tag/v1.7.0). We may leverage that in order to identify a replacement for the kamel install. We should analyze how that will happen and the user experience around any new way we’ll propose to the community.
+Another thread we should follow is related to the proposal about descoped OLM. This part should be put in a wider context around the OLM project.
+
+## API
+We can start thinking of Camel K as an enablement technology. Then, it makes sense to dedicate some effort in improving the way the technology may be consumed by others. APIs and CRDs are the main scope of this section.
+
+* Provide a full description of the APIs
+* Comprehensive CRD structural schemas for tooling
+* Traits configuration schema ([#1614](https://github.com/apache/camel-k/issues/1614))
+
+Implementation of structural schema may be the goal of 2.0 as will probably require many breaking changes. Some draft was realized and it provided discussions we may take in consideration during the feature implementation (see [#2831](https://github.com/apache/camel-k/issues/2831)
Review comment:
```suggestion
Implementation of structural schema may be the goal of 2.0 as will probably require many breaking changes. Some draft was realized and it provided discussions we may take in consideration during the feature implementation (see [#2831](https://github.com/apache/camel-k/issues/2831)).
```
--
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
[GitHub] [camel-website] github-actions[bot] commented on pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
github-actions[bot] commented on pull request #795:
URL: https://github.com/apache/camel-website/pull/795#issuecomment-1055571378
🚀 Preview is available at https://pr-795--camel.netlify.app
--
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
[GitHub] [camel-website] apupier commented on a change in pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
apupier commented on a change in pull request #795:
URL: https://github.com/apache/camel-website/pull/795#discussion_r816749555
##########
File path: content/blog/2022/03/camel-k-roadmap-2022/index.md
##########
@@ -0,0 +1,116 @@
+---
+title: "Camel K 2022 Roadmap"
+date: 2022-03-01
+draft: false
+authors: [squakez]
+categories: ["Roadmap", "Camel K"]
+preview: "A brief overview of what we've planned for 2022"
+---
+
+<sub><sup><a href='https://pngtree.com/so/Signpost'>Signpost png from pngtree.com/</a></sup></sub>
+
+During the last weeks we've been asked questions around the direction we're willing to take on the future development of **Camel K**. I think it would be good to have some blog in order to let the community understand where our efforts are going. It will be useful for every Camel K user and Camel K developer, as a guide for the future development of the project.
+
+The below list of development areas are the ones identified at the end of 2021. The order is random, we haven't identified any clear priority yet. Some of those developments are already completed (fully or partially).
+
+* Code/build (release process)
+* Installation procedure
+* API
+* CLI
+* Event Driven Architecture
+* Builder (containers, images and registry)
+* Runtime (Integration execution)
+* Observability
+* Kamelets
+
+In each section, I've tried to detail the rationale and some ideas that can be furtherly refined. There may also be reference to Github issues that are related to the requirement under discussion.
+
+DISCLAIMER: this is a wide list of desired areas we may work on. We may not be able to complete all of them for any reason, neither considered responsible for any kind of committment. The contributors must not consider this as a mandatory list of work to do, but as a suggested list of things to take in consideration when dedicating time to the project.
+
+## Code/build (release process)
+The goal we identified is to simplify and speed up the release process.
+
+* Merge Camel K runtime into Camel Quarkus
+* Multi-architecture images ([#1238](https://github.com/apache/camel-k/issues/1238))
+* Modularised build ([#2801](https://github.com/apache/camel-k/issues/2801))
+* Nightly builds ([#393](https://github.com/apache/camel-k/issues/393))
+
+We now have a chain of relationships as `Camel K >> Camel K runtime >> Camel Quarkus >> Camel`. Camel K runtime could be seen as a bootstrap of `Camel Quarkus`: this approach simplifies the overall picture and releases dependencies. We may kick off joint initiative with **Camel Quarkus** community to bring the actual **Camel K Runtime**, under the Camel Quarkus umbrella.
+Through multi architecture images we will be able to widen our target audience by extending the presence of the **Operator** on different architectures. Nightly build will also let everybody use partial fixes before any official release cycle.
+
+## Installation procedure
+We have several installation process options in place. We may need to harmonize them to simplify the maintenance of the installation procedure.
+
+* Document the usage of Kustomize ([#2758](https://github.com/apache/camel-k/issues/2758))
+* Deprecate kamel install in favor of kubectl apply -k / kustomize
+* Move to descoped OLM model
+
+There is some preliminary work introduced in release 1.7 around [Kustomize](https://github.com/apache/camel-k/releases/tag/v1.7.0). We may leverage that in order to identify a replacement for the kamel install. We should analyze how that will happen and the user experience around any new way we’ll propose to the community.
+Another thread we should follow is related to the proposal about descoped OLM. This part should be put in a wider context around the OLM project.
+
+## API
+We can start thinking of Camel K as an enablement technology. Then, it makes sense to dedicate some effort in improving the way the technology may be consumed by others. APIs and CRDs are the main scope of this section.
+
+* Provide a full description of the APIs
+* Comprehensive CRD structural schemas for tooling
+* Traits configuration schema ([#1614](https://github.com/apache/camel-k/issues/1614))
+
+Implementation of structural schema may be the goal of 2.0 as will probably require many breaking changes. Some draft was realized and it provided discussions we may take in consideration during the feature implementation (see [#2831](https://github.com/apache/camel-k/issues/2831)
+
+## CLI
+The CLI is still a very useful tool when interacting with connected environments, in particular in the community.
+
+* Fill the gaps for kamel local commands
+* Enable JBang
+* Better auto-completion ([#2461](https://github.com/apache/camel-k/issues/2461))
+
+We have many requests to enhance the `kamel local` command in order to perform more actions. It seems this is used in order to test the Integrations, like a development environment. We may also investigate how to leverage **JBang** as it seems a better approach for local testing. As long as the development of JBang on Camel gather maturity, we will probably address the required changes to have it better integrated in Camel K.
+
+## Event Driven Architecture
+We can think of Camel K as a technology to be used in **Kubernetes** space for event driven architectures. For this reason we will work to enable certain aspects required by EDA.
+
+* Offset management
+* Source partitioning and load balancing
+* Integration with Keda auto-scalers
+* Knative stability
+* Kamelets support/stability
+
+Following the strategy of the EDA positioning, we should focus on creating a stable environment for **Knative**, **Kamelets** and **Kafka**. In the same direction we must explore the **Keda** ecosystem and how the first implementation fits into Camel K model.
+
+## Builder
+Integration building process needs to be tweaked in order to guarantee scalability. We may revisit parts of the process in order to be more “production grade”.
+
+* Improve concurrency / scalability ([#1784](https://github.com/apache/camel-k/issues/1784))
+* Image garbage collection / compaction ([#2736](https://github.com/apache/camel-k/issues/2736))
+* Support OCI registries for universal artifacts management ([#2732](https://github.com/apache/camel-k/issues/2732))
+* CI/CD support
+* Build Pod compute resources
+
+**[Mvnd](https://github.com/apache/maven-mvnd)** is a good candidate for improving the scalability of the builds. Some preliminary work already exists (see [#2832](https://github.com/apache/camel-k/issues/2832)). Some interesting work is already in place to provide layered images for dependencies (see [#2835](https://github.com/apache/camel-k/issues/2835)). There is certain demand for reducing the quantity of debris produced during the creation of images (ie, garbage collection) and to show how to integrate Camel K with some CI/CD tool.
+
+## Runtime
+Other efforts that will let Camel K be more mature are related to features around the runtime.
+
+* Improve route DSL parsing ([#1266](https://github.com/apache/camel-k/issues/1266))
+* Surface Camel health checks into integration status ([#2886](https://github.com/apache/camel-k/issues/2886)
+* Business vs. technical errors
+
+Route parsing has a great margin of improvement in order to automatically discover components, capabilities, dependencies, etc, and in general to be more reliable. Also, exposing more meaningful ways to query the healthy status of an Integration will let users speed up their troubleshooting (this part is almost completed in the latest releases).
+
+## Observability
+Monitoring running Integrations is another field which will let the user feel the maturity of the product.
+
+* Migrate from MicroProfile metrics to Micrometer
Review comment:
```suggestion
* Migrate from [MicroProfile](https://microprofile.io/) metrics to [Micrometer](https://micrometer.io/)
```
--
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
[GitHub] [camel-website] squakez commented on pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
squakez commented on pull request #795:
URL: https://github.com/apache/camel-website/pull/795#issuecomment-1056680219
Merge of this has clashed with some changes in Camel K API which are causing the failure in publish pipeline (https://ci-builds.apache.org/blue/organizations/jenkins/Camel%2FCamel.website/activity). I think they are solved now in the camel k `main` branch. Any possibility to re-run the pipeline? @oscerd @zregvart I tried on Jenkins, but I have no privileges over there.
--
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
[GitHub] [camel-website] apupier commented on a change in pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
apupier commented on a change in pull request #795:
URL: https://github.com/apache/camel-website/pull/795#discussion_r816752924
##########
File path: content/blog/2022/03/camel-k-roadmap-2022/index.md
##########
@@ -0,0 +1,116 @@
+---
+title: "Camel K 2022 Roadmap"
+date: 2022-03-01
+draft: false
+authors: [squakez]
+categories: ["Roadmap", "Camel K"]
+preview: "A brief overview of what we've planned for 2022"
+---
+
+<sub><sup><a href='https://pngtree.com/so/Signpost'>Signpost png from pngtree.com/</a></sup></sub>
+
+During the last weeks we've been asked questions around the direction we're willing to take on the future development of **Camel K**. I think it would be good to have some blog in order to let the community understand where our efforts are going. It will be useful for every Camel K user and Camel K developer, as a guide for the future development of the project.
+
+The below list of development areas are the ones identified at the end of 2021. The order is random, we haven't identified any clear priority yet. Some of those developments are already completed (fully or partially).
+
+* Code/build (release process)
+* Installation procedure
+* API
+* CLI
+* Event Driven Architecture
+* Builder (containers, images and registry)
+* Runtime (Integration execution)
+* Observability
+* Kamelets
+
+In each section, I've tried to detail the rationale and some ideas that can be furtherly refined. There may also be reference to Github issues that are related to the requirement under discussion.
+
+DISCLAIMER: this is a wide list of desired areas we may work on. We may not be able to complete all of them for any reason, neither considered responsible for any kind of committment. The contributors must not consider this as a mandatory list of work to do, but as a suggested list of things to take in consideration when dedicating time to the project.
+
+## Code/build (release process)
+The goal we identified is to simplify and speed up the release process.
+
+* Merge Camel K runtime into Camel Quarkus
+* Multi-architecture images ([#1238](https://github.com/apache/camel-k/issues/1238))
+* Modularised build ([#2801](https://github.com/apache/camel-k/issues/2801))
+* Nightly builds ([#393](https://github.com/apache/camel-k/issues/393))
+
+We now have a chain of relationships as `Camel K >> Camel K runtime >> Camel Quarkus >> Camel`. Camel K runtime could be seen as a bootstrap of `Camel Quarkus`: this approach simplifies the overall picture and releases dependencies. We may kick off joint initiative with **Camel Quarkus** community to bring the actual **Camel K Runtime**, under the Camel Quarkus umbrella.
+Through multi architecture images we will be able to widen our target audience by extending the presence of the **Operator** on different architectures. Nightly build will also let everybody use partial fixes before any official release cycle.
+
+## Installation procedure
+We have several installation process options in place. We may need to harmonize them to simplify the maintenance of the installation procedure.
+
+* Document the usage of Kustomize ([#2758](https://github.com/apache/camel-k/issues/2758))
+* Deprecate kamel install in favor of kubectl apply -k / kustomize
+* Move to descoped OLM model
+
+There is some preliminary work introduced in release 1.7 around [Kustomize](https://github.com/apache/camel-k/releases/tag/v1.7.0). We may leverage that in order to identify a replacement for the kamel install. We should analyze how that will happen and the user experience around any new way we’ll propose to the community.
+Another thread we should follow is related to the proposal about descoped OLM. This part should be put in a wider context around the OLM project.
+
+## API
+We can start thinking of Camel K as an enablement technology. Then, it makes sense to dedicate some effort in improving the way the technology may be consumed by others. APIs and CRDs are the main scope of this section.
+
+* Provide a full description of the APIs
+* Comprehensive CRD structural schemas for tooling
Review comment:
```suggestion
* Comprehensive Custom Resource Definition (CRD) structural schemas for tooling
```
--
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
[GitHub] [camel-website] squakez merged pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
squakez merged pull request #795:
URL: https://github.com/apache/camel-website/pull/795
--
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
[GitHub] [camel-website] github-actions[bot] commented on pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
github-actions[bot] commented on pull request #795:
URL: https://github.com/apache/camel-website/pull/795#issuecomment-1055569253
--
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
[GitHub] [camel-website] squakez commented on pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
squakez commented on pull request #795:
URL: https://github.com/apache/camel-website/pull/795#issuecomment-1056692246
> I started a new website build https://ci-builds.apache.org/job/Camel/job/Camel.website/job/main/768/
great, thanks @davsclaus !
--
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
[GitHub] [camel-website] apupier commented on a change in pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
apupier commented on a change in pull request #795:
URL: https://github.com/apache/camel-website/pull/795#discussion_r816748275
##########
File path: content/blog/2022/03/camel-k-roadmap-2022/index.md
##########
@@ -0,0 +1,116 @@
+---
+title: "Camel K 2022 Roadmap"
+date: 2022-03-01
+draft: false
+authors: [squakez]
+categories: ["Roadmap", "Camel K"]
+preview: "A brief overview of what we've planned for 2022"
+---
+
+<sub><sup><a href='https://pngtree.com/so/Signpost'>Signpost png from pngtree.com/</a></sup></sub>
+
+During the last weeks we've been asked questions around the direction we're willing to take on the future development of **Camel K**. I think it would be good to have some blog in order to let the community understand where our efforts are going. It will be useful for every Camel K user and Camel K developer, as a guide for the future development of the project.
+
+The below list of development areas are the ones identified at the end of 2021. The order is random, we haven't identified any clear priority yet. Some of those developments are already completed (fully or partially).
+
+* Code/build (release process)
+* Installation procedure
+* API
+* CLI
+* Event Driven Architecture
+* Builder (containers, images and registry)
+* Runtime (Integration execution)
+* Observability
+* Kamelets
+
+In each section, I've tried to detail the rationale and some ideas that can be furtherly refined. There may also be reference to Github issues that are related to the requirement under discussion.
+
+DISCLAIMER: this is a wide list of desired areas we may work on. We may not be able to complete all of them for any reason, neither considered responsible for any kind of committment. The contributors must not consider this as a mandatory list of work to do, but as a suggested list of things to take in consideration when dedicating time to the project.
+
+## Code/build (release process)
+The goal we identified is to simplify and speed up the release process.
+
+* Merge Camel K runtime into Camel Quarkus
+* Multi-architecture images ([#1238](https://github.com/apache/camel-k/issues/1238))
+* Modularised build ([#2801](https://github.com/apache/camel-k/issues/2801))
+* Nightly builds ([#393](https://github.com/apache/camel-k/issues/393))
+
+We now have a chain of relationships as `Camel K >> Camel K runtime >> Camel Quarkus >> Camel`. Camel K runtime could be seen as a bootstrap of `Camel Quarkus`: this approach simplifies the overall picture and releases dependencies. We may kick off joint initiative with **Camel Quarkus** community to bring the actual **Camel K Runtime**, under the Camel Quarkus umbrella.
+Through multi architecture images we will be able to widen our target audience by extending the presence of the **Operator** on different architectures. Nightly build will also let everybody use partial fixes before any official release cycle.
+
+## Installation procedure
+We have several installation process options in place. We may need to harmonize them to simplify the maintenance of the installation procedure.
+
+* Document the usage of Kustomize ([#2758](https://github.com/apache/camel-k/issues/2758))
+* Deprecate kamel install in favor of kubectl apply -k / kustomize
+* Move to descoped OLM model
+
+There is some preliminary work introduced in release 1.7 around [Kustomize](https://github.com/apache/camel-k/releases/tag/v1.7.0). We may leverage that in order to identify a replacement for the kamel install. We should analyze how that will happen and the user experience around any new way we’ll propose to the community.
+Another thread we should follow is related to the proposal about descoped OLM. This part should be put in a wider context around the OLM project.
+
+## API
+We can start thinking of Camel K as an enablement technology. Then, it makes sense to dedicate some effort in improving the way the technology may be consumed by others. APIs and CRDs are the main scope of this section.
+
+* Provide a full description of the APIs
+* Comprehensive CRD structural schemas for tooling
+* Traits configuration schema ([#1614](https://github.com/apache/camel-k/issues/1614))
+
+Implementation of structural schema may be the goal of 2.0 as will probably require many breaking changes. Some draft was realized and it provided discussions we may take in consideration during the feature implementation (see [#2831](https://github.com/apache/camel-k/issues/2831)
+
+## CLI
+The CLI is still a very useful tool when interacting with connected environments, in particular in the community.
+
+* Fill the gaps for kamel local commands
+* Enable JBang
+* Better auto-completion ([#2461](https://github.com/apache/camel-k/issues/2461))
+
+We have many requests to enhance the `kamel local` command in order to perform more actions. It seems this is used in order to test the Integrations, like a development environment. We may also investigate how to leverage **JBang** as it seems a better approach for local testing. As long as the development of JBang on Camel gather maturity, we will probably address the required changes to have it better integrated in Camel K.
+
+## Event Driven Architecture
+We can think of Camel K as a technology to be used in **Kubernetes** space for event driven architectures. For this reason we will work to enable certain aspects required by EDA.
+
+* Offset management
+* Source partitioning and load balancing
+* Integration with Keda auto-scalers
+* Knative stability
+* Kamelets support/stability
+
+Following the strategy of the EDA positioning, we should focus on creating a stable environment for **Knative**, **Kamelets** and **Kafka**. In the same direction we must explore the **Keda** ecosystem and how the first implementation fits into Camel K model.
+
+## Builder
+Integration building process needs to be tweaked in order to guarantee scalability. We may revisit parts of the process in order to be more “production grade”.
+
+* Improve concurrency / scalability ([#1784](https://github.com/apache/camel-k/issues/1784))
+* Image garbage collection / compaction ([#2736](https://github.com/apache/camel-k/issues/2736))
+* Support OCI registries for universal artifacts management ([#2732](https://github.com/apache/camel-k/issues/2732))
+* CI/CD support
+* Build Pod compute resources
+
+**[Mvnd](https://github.com/apache/maven-mvnd)** is a good candidate for improving the scalability of the builds. Some preliminary work already exists (see [#2832](https://github.com/apache/camel-k/issues/2832)). Some interesting work is already in place to provide layered images for dependencies (see [#2835](https://github.com/apache/camel-k/issues/2835)). There is certain demand for reducing the quantity of debris produced during the creation of images (ie, garbage collection) and to show how to integrate Camel K with some CI/CD tool.
+
+## Runtime
+Other efforts that will let Camel K be more mature are related to features around the runtime.
+
+* Improve route DSL parsing ([#1266](https://github.com/apache/camel-k/issues/1266))
+* Surface Camel health checks into integration status ([#2886](https://github.com/apache/camel-k/issues/2886)
Review comment:
```suggestion
* Surface Camel health checks into integration status ([#2886](https://github.com/apache/camel-k/issues/2886))
```
--
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
[GitHub] [camel-website] davsclaus commented on pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
davsclaus commented on pull request #795:
URL: https://github.com/apache/camel-website/pull/795#issuecomment-1056685681
I started a new website build
https://ci-builds.apache.org/job/Camel/job/Camel.website/job/main/768/
--
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
[GitHub] [camel-website] github-actions[bot] commented on pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
github-actions[bot] commented on pull request #795:
URL: https://github.com/apache/camel-website/pull/795#issuecomment-1054368284
🚀 Preview is available at https://pr-795--camel.netlify.app
--
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
[GitHub] [camel-website] apupier commented on a change in pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
apupier commented on a change in pull request #795:
URL: https://github.com/apache/camel-website/pull/795#discussion_r816753374
##########
File path: content/blog/2022/03/camel-k-roadmap-2022/index.md
##########
@@ -0,0 +1,116 @@
+---
+title: "Camel K 2022 Roadmap"
+date: 2022-03-01
+draft: false
+authors: [squakez]
+categories: ["Roadmap", "Camel K"]
+preview: "A brief overview of what we've planned for 2022"
+---
+
+<sub><sup><a href='https://pngtree.com/so/Signpost'>Signpost png from pngtree.com/</a></sup></sub>
+
+During the last weeks we've been asked questions around the direction we're willing to take on the future development of **Camel K**. I think it would be good to have some blog in order to let the community understand where our efforts are going. It will be useful for every Camel K user and Camel K developer, as a guide for the future development of the project.
+
+The below list of development areas are the ones identified at the end of 2021. The order is random, we haven't identified any clear priority yet. Some of those developments are already completed (fully or partially).
+
+* Code/build (release process)
+* Installation procedure
+* API
+* CLI
+* Event Driven Architecture
+* Builder (containers, images and registry)
+* Runtime (Integration execution)
+* Observability
+* Kamelets
+
+In each section, I've tried to detail the rationale and some ideas that can be furtherly refined. There may also be reference to Github issues that are related to the requirement under discussion.
+
+DISCLAIMER: this is a wide list of desired areas we may work on. We may not be able to complete all of them for any reason, neither considered responsible for any kind of committment. The contributors must not consider this as a mandatory list of work to do, but as a suggested list of things to take in consideration when dedicating time to the project.
+
+## Code/build (release process)
+The goal we identified is to simplify and speed up the release process.
+
+* Merge Camel K runtime into Camel Quarkus
+* Multi-architecture images ([#1238](https://github.com/apache/camel-k/issues/1238))
+* Modularised build ([#2801](https://github.com/apache/camel-k/issues/2801))
+* Nightly builds ([#393](https://github.com/apache/camel-k/issues/393))
+
+We now have a chain of relationships as `Camel K >> Camel K runtime >> Camel Quarkus >> Camel`. Camel K runtime could be seen as a bootstrap of `Camel Quarkus`: this approach simplifies the overall picture and releases dependencies. We may kick off joint initiative with **Camel Quarkus** community to bring the actual **Camel K Runtime**, under the Camel Quarkus umbrella.
+Through multi architecture images we will be able to widen our target audience by extending the presence of the **Operator** on different architectures. Nightly build will also let everybody use partial fixes before any official release cycle.
+
+## Installation procedure
+We have several installation process options in place. We may need to harmonize them to simplify the maintenance of the installation procedure.
+
+* Document the usage of Kustomize ([#2758](https://github.com/apache/camel-k/issues/2758))
+* Deprecate kamel install in favor of kubectl apply -k / kustomize
+* Move to descoped OLM model
+
+There is some preliminary work introduced in release 1.7 around [Kustomize](https://github.com/apache/camel-k/releases/tag/v1.7.0). We may leverage that in order to identify a replacement for the kamel install. We should analyze how that will happen and the user experience around any new way we’ll propose to the community.
+Another thread we should follow is related to the proposal about descoped OLM. This part should be put in a wider context around the OLM project.
+
+## API
+We can start thinking of Camel K as an enablement technology. Then, it makes sense to dedicate some effort in improving the way the technology may be consumed by others. APIs and CRDs are the main scope of this section.
Review comment:
```suggestion
We can start thinking of Camel K as an enablement technology. Then, it makes sense to dedicate some effort in improving the way the technology may be consumed by others. APIs and Custom Resource Definitions (CRD) are the main scope of this section.
```
--
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
[GitHub] [camel-website] apupier commented on a change in pull request #795: chore: Camel K roadmap 2022
Posted by GitBox <gi...@apache.org>.
apupier commented on a change in pull request #795:
URL: https://github.com/apache/camel-website/pull/795#discussion_r816755350
##########
File path: content/blog/2022/03/camel-k-roadmap-2022/index.md
##########
@@ -0,0 +1,116 @@
+---
+title: "Camel K 2022 Roadmap"
+date: 2022-03-01
+draft: false
+authors: [squakez]
+categories: ["Roadmap", "Camel K"]
+preview: "A brief overview of what we've planned for 2022"
Review comment:
```suggestion
preview: "A brief overview of what we've planned for Camel K in 2022"
```
--
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