Test and document how to use the kamel cmd as a kubectl plugin

[astefanutti]

See https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/

[github-actions[bot]]

This issue has been automatically marked as stale due to 90 days of inactivity. It will be closed if no further activity occurs within 15 days. If you think that’s incorrect or the issue should never stale, please simply write any comment. Thanks for your contributions!

[Komal7209]

Is this issue being assigned to someone? @astefanutti , If not could you assign this to me

[Komal7209]

Hi @astefanutti Could you give me link to some other document according to which I need to document all the things which are mentioned in above document or is there some template for the same?

[squakez]

I think you can make some example similar to what is done in the example directory. As a structure, have a look for instance at this example: https://github.com/apache/camel-k/tree/main/examples/kamelets/error-handler - you can make a step by step sort of tutorial to show some basic usage.

[tdiesler]

A plugin is a standalone executable file, whose name begins with kubectl-. To install a plugin, move its executable file to anywhere on your PATH.

You can also discover and install kubectl plugins available in the open source using Krew. Krew is a plugin manager maintained by the Kubernetes SIG CLI community.

https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/#installing-kubectl-plugins

Do we already have such a binary? git grep kubectl-camel and the krew-index show nothing.

[squakez]

Probably the goal of the issue was to create and document it. I am not aware of such a plugin either.

[tdiesler]

Ok, let me take care of that - it seems a good task to get in touch with many things.

I can see two possible approaches ...

1. Plugin is a thin wrapper and calls an already existing kamel binary
2. Plugin is a standalone binary that delegates to pkg/cmd and possibly other API

The first approach is cheap, but would require an external dependency. The second approach opens a new distribution channel (i.e. kubectl krew install camel) and gives the stuff that we have already more visibility. The plugin would inherently share the same lifecycle as camel-k

I'd prefer the second approach

[squakez]

Mind that the CLI is meant to disappear any time soon and we've limited the development to bug fix only. Any CLI related effort has to be done on Camel JBang side. Please check with @christophd if/how it would be possible to join the effort toward that project.

[tdiesler]

Will do

[tdiesler]

I would look like this ... https://github.com/tdiesler/camel-k/tree/ghi471

[squakez]

@tdiesler but this would still use kamel CLI. Given the effort we're moving everything to camel (jbang) I'd strongly encourage to make any development targeting such a CLI instead.