You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by "astefanutti (via GitHub)" <gi...@apache.org> on 2023/03/28 09:49:14 UTC

[GitHub] [camel-k] astefanutti commented on pull request #4156: feat: change KameletBinding name to Binding

astefanutti commented on PR #4156:
URL: https://github.com/apache/camel-k/pull/4156#issuecomment-1486547810

   > the main issue would be that you cannot upgrade an operator to v2 so I think we should either support KameletBinding and Binding for some time or having an automated upgrade strategy (maybe via a webhook) ? @astefanutti WDYT ?
   
   @lburgazzoli changing resource names in Kubernetes isn't possible (the name field is immutable after creation), which makes existing versioning and conversion mechanisms inapplicable to this case, e.g., for CRD conversion webhook:
   
   https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#permissible-mutations
   
   Practically, simply changing the CRD name will create a new type, and leave the existing CRD as is, along with its instances, which will be ignored by the v2 operator.
   
   To provide a smoother migration path, the simplest option would be to support both KameletBinding and Binding resource types as you suggested. It may also be possible to write an ad-hoc conversion controller as a more advanced strategy.


-- 
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-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org