Hierarchical traits configuration CLI

[astefanutti]

While the trait configuration could be structured and hierarchical, it is currently limited by the flat CLI used for trait configuration. For example, if hierarchical CLI would be supported, it would be possible to execute:

$ kamel run -t route.tls.termination=... -t route.tls.certificate=... -t route.tls.key=...

Instead of:

$ kamel run -t route.tls-termination=... -t route.tls-certificate=... -t route.tls-key=...

The major benefit would be that Kubernetes/OpenShift API types could be reused directly, i.e. in that example TLSConfig.

Another example would be the container trait, where all the resource, liveness and readiness related fields would be structured together.

Also, labels would ideally be stored in maps, instead of string arrays of key/value pairs.

Also, the configuration, serialised into the Integration, IntegrationKit and IntegrationPlatform would be structured, hence more legible.

This will impact documentation generation and tooling.

[github-actions]

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!