feat(cli): environment promotion

[squakez]

With this PR the user can run:

kamel promote sample -n development --to production

in order to copy the Integration spec and the related container image from one environment (namespace) to another. In order to work the Operators have to share the same Image registry.

Features:

• Check compatibility version between source and dest operators
• Verify namespaced resources (ie, mount traits) are present in dest namespace
• Verify the operators registries are the same
• Verify Kamelets are available in dest namespace
• Copy the Integration spec from namespace source to ns dest
• Set container.image trait on destination to reuse image (tested) from the source Integration

Release Note

feat(cli): environment promotion

[tadayosi]

Looks great! Here is my early feedback on the feature:

• What if the dev namespace uses a local operator but the production depends on a cluster operator (or vice versa)? Is such promotion not allowed?
• Do we need to check user's privileges for the target namespace? Or is it ok to let it fail if they are not permitted?
• Users might want to transform some labels (or annotations) depending on the types of envs (namespaces). Should we provide such feature as well?

[squakez]

Thanks for the feedback, much appreciated!!

* What if the dev namespace uses a local operator but the production depends on a cluster operator (or vice versa)?  Is such promotion not allowed?

I think it still can be done. The idea is that we copy the Integration spec plus the container which was tested and validated in a previous stage. I think the destination operator should be still able to cope with that.

* Do we need to check user's privileges for the target namespace?  Or is it ok to let it fail if they are not permitted?

We may understand which is the best ux there. If I am not wrong, the client we use to interact with the cluster is inheriting privileges from the user who has performed the login. I guess in a very first iteration we can let it fail, and add a check for valid permission in a later stage if we want.

* Users might want to transform some labels (or annotations) depending on the types of envs (namespaces). Should we provide such feature as well?

Yeah, that is something we should analyze better. I've already thought we should check for various resources in the destination namespace. We should include also some parameter in order to transform the "typical" resources bound to an environment (annotations, envs, affininity/tolerations, etc...).