squakez commented on PR #12474:
URL: https://github.com/apache/camel/pull/12474#issuecomment-1864319463
> > 3. the get command has been called get for all its life in camel-k, and
we use same name in camel-jbang, so I think its not a good idea to rename it to
list (old habbits die hard)
>
> I see that the `camel get` provides many more details. I guess the `list`
command I was doing here in this PR is more like the `camel ps` command. Should
I use `camel k ps` then? I personally don't like `ps` very much so I am ok to
use `camel k get` but just wanted to get some feedback. @davsclaus @oscerd
@squakez
IMO neither. The user should be able to list and operate via `kubectl` or
any other Kubernetes tool as he normally does. The `camel k run` should be the
only facility that we offer in my opinion. We may even not require to push the
Integration to the cluster at all if we want. The ultimate feature it should
offer is to create an Integration custom resource with the parameters provided
by the user (here we should try to give the majority of parameters provided in
the `kamel run`). We may have something like:
```
$ camel k run test.yaml
apiVersion: camel.apache.org/v1
kind: Integration
metadata:
annotations:
camel.apache.org/operator.id: camel-k
creationTimestamp: null
name: test
spec:
flows:
- from:
parameters:
period: "1000"
steps:
- setBody:
simple: Hello Camel from ${routeId}
- log: ${body}
uri: timer:yaml
traits: {}
```
and in order to apply on the cluster we may have something like a piped
command in conjunction with kubectl/oc:
```
$ camel k run test.yaml | kubectl apply -f -
integration.camel.apache.org/test created
```
--
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
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
