[GitHub] [camel-website] zregvart commented on a change in pull request #677: feat: camel k 1.7 announcement

[GitBox <gi...@apache.org>]

zregvart commented on a change in pull request #677:
URL: https://github.com/apache/camel-website/pull/677#discussion_r751524331



##########
File path: content/blog/2021/11/camel-k-release-1-7/index.md
##########
@@ -0,0 +1,106 @@
+---
+title: "Camel K 1.7 release"
+date: 2021-11-17
+draft: false
+authors: [squakez]
+categories: ["Releases", "Camel K"]
+preview: "What's new in Camel K 1.7"
+---
+
+Today we're happy to announce a new major release for Camel K: [Camel K 1.7 version](https://github.com/apache/camel-k/releases/tag/v1.7.0), quite a big leap from latest 1.6 we released a couple of months ago. Keep reading to discover what's new in Camel K! 
+
+First of all, let's highlight the set of technologies on which Camel K 1.7 is based:
+
+* Apache Camel K Runtime 1.10.0
+* Apache Camel Quarkus 2.4.0
+* Apache Camel 3.12.0
+* Apache Camel Kamelets 0.5.0
+
+Thanks to Apache Camel, Camel Quarkus and Kamelet Catalog contributors for the great effor they've put in those new releases as well.
+
+## Dependencies upgrade
+
+The upgrades we applied in this new release, deserve a dedicate section.
+
+We upgraded `Golang` version to `1.6` which gave us the possibility to **bump several Kubernetes API** and so, be in line with the latest enhancements released in K8S space. We also moved to the latest `maven` version, which now point to `3.8.3`. We took the opportunity to promote `Knative` and `Service Binding` to their first `1.x` stable release and to move `Jolokia` to version `1.7.1`. You can find more details on the [GitHub release page](https://github.com/apache/camel-k/releases/tag/v1.7.0).
+
+## Quarkus native build support
+
+The most exciting and promising feature we brought in Camel K 1.7 is probably the support for `Quarkus` native build. If you're not yet aware of it, Quarkus is the great technology that allows your Java application to **run as fast as any native compiled application**. That helps reducing the resource footprint and reduce almost to zero the startup time, making your application a `Cloud Native` first class citizen.
+
+It was a long development and we're still polishing few things before adding official documentation (will do soon, keep tuned). You can find some useful information in the [discussion done during the development](https://github.com/apache/camel-k/pull/2536). The resume is that you can now launch your Camel application with a Quarkus Native profile:
+
+```
+$ kamel run -t quarkus.package-type=native ...
+```
+The build will need some time and some more resource than usual (average test of 5 minutes and 4GB of memory, but it will depend on each case) as there is an ahead of time compilation. The great news is that we thought that, while your native application is building, you can benefit the JVM mode as done normally so far:
+```
+$ kamel run -t quarkus.package-type=fast-jar -t quarkus.package-type=native ...
+```
+The Quarkus JVM application will be replaced with a rolling deployment update as soon as the native build will be completed!
+
+We will provide more official documentation soon. In the while, feel free to try it and report any problem, feedback or suggestion, we'd love to hear about how you're using it.
+
+This feature deserves a special mention to [Antonin Stefanutti](https://github.com/astefanutti) who has lead its development.
+
+## Installation and build improvements
+
+In the last release we've dedicated some time to include improvements about the way you can customize your Camel K installation on a Kubernetes cluster.
+
+### Kustomize
+
+Let's start with the introduction of [Kustomize](https://kustomize.io/). Here the extract of the feature to be soon documented officially:
+
+The `config` directory contains all the resources for installation and configuration of the camel-k operator. While, by default, those resource are installed through the `kamel` binary, they can also be applied directly to a cluster using `kustomize`. These resources can be modified prior to their installation and the `kustomize.yaml` files be changed to **include extra patches and settings**, as required.
+
+More details on how to use it can be found in the [release page](https://github.com/apache/camel-k/releases/tag/v1.7.0).
+
+### Custom labels
+
+Sometimes you may be interested to **introduce certain custom labels** to all the `Pods` running for all your `Integrations`. In such circumstances, you can build the Camel K operator on your own and leverage the presence of a new `Golflag` to set certain information that will be configured and then executed from the operator:
+```
+GOLDFLAGS += -X github.com/apache/camel-k/pkg/util/label.AdditionalLabels=department=Accounting;version=1.2.3;int-name=token_integration_name
+```
+With this simple configuration, you can let each `Integration` to inherit those `Labels` automatically, withouth having to declare them every time. Discover more information about the [custom label feature](https://github.com/apache/camel-k/pull/2646).
+
+## Polished Integration status
+
+This one is a series of improvements to **include more descriptive information** related to the status of the integration. In particular we've worked to a couple of features that introduced a more detailed error reporting in the `Integration` and more reliability about the scaling status.
+
+## Secondary Integration Platform
+
+So far, a single operator was able to manage the `Integration` created on a namespace. This simple model was a bit limiting, as we were not able to distinguish a way to have more than one operator on the same namespace. With the new feature developed, now you will be able to declare a secondary `Integration Platform` and **have more than one operator** collaborating on the same `Namespace`. This is an advanced feature that will let you unlock more advanced deployment topology in order to have a [more scalable and resilient configuration](/camel-k/next/architecture/advanced.html).
+
+## Traits enhancements
+
+We have worked to a few interesting enhancements on the following traits:
+
+* [Health](/camel-k/next/traits/health.html)
+* [Camel](/camel-k/next/traits/camel.html)
+* [Route](/camel-k/next/traits/route.html)
+
+The new `health` trait was introduced to replace the responsibility of exposing the endpoint from `container` trait, encapsulating its responsibility in this self contained new trait.
+
+We also moved the responsibility of `properties` from `deployment`, `cron` and `knative_service` to `camel` trait, in order to have a unique place where to manage this aspect.
+
+Finally, in `route` trait we added the possibility to read certificates directly from Kubernetes `Secrets` instead of passing them as text.
+
+## More Kamelet love
+
+The [Apache Camel Kamelet Catalog](/camel-kamelets/next/index.html) keeps growing. We are also fixing the issue reported and making them more stable and consistent with the latest development delivered in Apache Camel ecosystem.
+
+Let's also share some interesting news about the `Kamelets` world, as lately they became **one the stars of [ApacheCon](https://www.apachecon.com/)** with [a very nice presentation by Nicola Ferraro](https://www.youtube.com/watch?v=xVL1gJ5AJVg).
+
+Also, let's remind a new interesting project we've already seen in some previous post, called [Karavan](blog/2021/10/camel-karavan-preview-release/), whose one of the goals is to **simplify the usage/managment** of `Kamelets`.

Review comment:
       ```suggestion
   Also, let's remind a new interesting project we've already seen in some previous post, called [Karavan](/blog/2021/10/camel-karavan-preview-release/), whose one of the goals is to **simplify the usage/managment** of `Kamelets`.
   ```
   
   Typo in the url...




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