mertdotcc opened a new issue, #4271:
URL: https://github.com/apache/camel-k/issues/4271
The title might not be 100% on point so you guys feel free to change it.
Consider the following `kamel run` command:
```
kamel run \
--config configmap:my-configmap/platform.baseUrl \
--config secret:my-secret/platform.auth-token \
--open-api file:./resources/platform-openapi.yaml \
--resource file:./resources/platform-template-response.json \
--resource file:./resources/sample-error-response.json \
--dependency mvn:org.mapstruct:mapstruct:1.5.2.Final \
--dependency
mvn:com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.14.2 \
--dependency camel:jackson
--source ./sources/PlatformBean.java \
--trait container.enabled=true \
--trait container.request-cpu="100m" \
--trait container.request-memory="128Mi" \
--trait container.limit-cpu="250m" \
--trait container.limit-memory="256Mi" \
--trait container.port=8443 \
--trait health.enabled=true \
--trait health.liveness-probe-enabled=true \
--trait health.liveness-scheme="HTTP" \
--trait health.liveness-initial-delay=0 \
--trait health.liveness-timeout=10 \
--trait health.liveness-period=15 \
--trait health.liveness-success-threshold=1 \
--trait health.liveness-failure-threshold=3 \
--trait health.readiness-probe-enabled=true \
--trait health.readiness-scheme="HTTP" \
--trait health.readiness-initial-delay=0 \
--trait health.readiness-timeout=10 \
--trait health.readiness-period=15 \
--trait health.readiness-success-threshold=1 \
--trait health.readiness-failure-threshold=3 \
--trait knative-service.enabled=true \
--trait knative-service.autoscaling-class="kpa.autoscaling.knative.dev" \
--trait knative-service.autoscaling-metric="rps" \
--trait knative-service.autoscaling-target=100 \
--trait knative-service.min-scale=0 \
--trait knative-service.max-scale=20 \
--trait prometheus.enabled=true \
--trait prometheus.pod-monitor=true \
--trait prometheus.pod-monitor-labels="release=kube-prometheus-stack" \
--trait quarkus.enabled=true \
--trait quarkus.package-type=native \
GrandCentral.java
```
This is quite a long `kamel run` command. We usually keep these in a
`run.sh` file for each integration and let the CI/CD pipeline run these shell
files. The thing is, the content of our `run.sh` files share a lot of code
between them, resulting in unnecessary duplication. Also, we have some
developers with Java background writing these integrations, and they are not
(and should not) be too bothered with all these trait configurations. We have
dedicated people with decent Kubernetes, Knative, Istio, etc experience that
usually prepares these platform-specific trait customizations and audits them.
The idea I have is roughly the following:
- I would like to create a `TraitProfile` (?) named
`Knative-Enabled-100-RPS-Min-Scale-0` with the following content:
```
--trait knative-service.enabled=true
--trait knative-service.autoscaling-class="kpa.autoscaling.knative.dev"
--trait knative-service.autoscaling-metric="rps"
--trait knative-service.autoscaling-target=100
--trait knative-service.min-scale=0
--trait knative-service.max-scale=20
```
- Another `TraitProfile` named `Quarkus-Native` with the following content:
```
--trait quarkus.enabled=true
--trait quarkus.package-type=native
```
- Another `TraitProfile` named `Default-Health-Config` with the following
content:
```
--trait health.enabled=true
--trait health.liveness-probe-enabled=true
--trait health.liveness-scheme="HTTP"
--trait health.liveness-initial-delay=0
--trait health.liveness-timeout=10
--trait health.liveness-period=15
--trait health.liveness-success-threshold=1
--trait health.liveness-failure-threshold=3
--trait health.readiness-probe-enabled=true
--trait health.readiness-scheme="HTTP"
--trait health.readiness-initial-delay=0
--trait health.readiness-timeout=10
--trait health.readiness-period=15
--trait health.readiness-success-threshold=1
--trait health.readiness-failure-threshold=3
```
- And finally, another `TraitProfile` named `Container-Limit-250m-256Mi`:
```
--trait container.enabled=true
--trait container.request-cpu="100m"
--trait container.request-memory="128Mi"
--trait container.limit-cpu="250m"
--trait container.limit-memory="256Mi"
--trait container.port=8443
```
- And re-use these profiles in my `kamel run` command as such:
```
kamel run \
--config configmap:my-configmap/platform.baseUrl \
--config secret:my-secret/platform.auth-token \
--open-api file:./resources/platform-openapi.yaml \
--resource file:./resources/platform-template-response.json \
--resource file:./resources/sample-error-response.json \
--dependency mvn:org.mapstruct:mapstruct:1.5.2.Final \
--dependency
mvn:com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.14.2 \
--dependency camel:jackson
--source ./sources/PlatformBean.java \
--trait-profile Knative-Enabled-100-RPS-Min-Scale-0 \
--trait-profile Quarkus-Native \
--trait-profile Default-Health-Config \
--trait-profile Container-Limit-250m-256Mi \
```
This, IMHO, would be a great addition to Camel-K as it is something we would
use everywhere. These profiles would be installed onto the Kubernetes platform,
just like Kamelets, and the developers would be able to browse through them. A
developer whose focus is to write integrations wouldn't be worried about these
configurations. A platform engineer who is well-versed in Knative, Istio, etc
but not aware of the `kamel` CLI syntax would just write these `TraitProfile`
customizations in a YAML and `kubectl apply` them as `CRDs`. Same platform
engineer would be able to replace `Knative-Enabled-100-RPS-Min-Scale-0` with
`Knative-Enabled-250-RPS-Min-Scale-1` for example; resulting in fast iterations.
Something *roughly* like this:
```
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
labels:
app: camel-k
name: traitprofiles.camel.apache.org
spec:
group: camel.apache.org
names:
kind: TraitProfile
listKind: TraitProfileList
plural: traitprofiles
shortNames:
- tp
singular: traitprofile
...
```
And the actual `TraitProfile` YAML spec would look something like this:
```
apiVersion: camel.apache.org/v1beta1
kind: TraitProfile
metadata:
name: Knative-Enabled-100-RPS-Min-Scale-0
spec:
traits:
knative-service:
autoscalingMetric: rps
autoscalingTarget: 100
class: kpa.autoscaling.knative.dev
enabled: true
maxScale: 20
minScale: 1
...
```
What do you guys think? I am aware of we already have something called
`"Trait Profiles"` as per
[this](https://github.com/apache/camel-k/blob/main/docs/modules/traits/pages/traits.adoc#configure-the-integration-spec)
but I see no usage/showcase of that besides the Knative, Kubernetes, and
Openshift profiles. And these three are rather pre-defined profiles that the
platform uses. So I am under the impression that the existing `"Trait
Profiles"` are not exactly for what I am proposing here. Please correct me if I
am wrong. I got confused by this so I created [this
issue](https://github.com/apache/camel-k-examples/issues/78).
--
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-unsubscr...@camel.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
