You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by "squakez (via GitHub)" <gi...@apache.org> on 2023/03/28 09:41:35 UTC
[GitHub] [camel-k] squakez opened a new issue, #4179: Camel K 2.x upgrade 1.x strategy
squakez opened a new issue, #4179:
URL: https://github.com/apache/camel-k/issues/4179
_Originally posted by @squakez in https://github.com/apache/camel-k/issues/4156#issuecomment-1486534406_
As we are moving to a new version (which may have its own sets of API) which may require breaking change to V1, I wonder if it makes sense and how should be an upgrade process. I think the main problem would be any running Integration, how should we make this transition happens correctly?
--
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.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] lburgazzoli commented on issue #4179: Camel K 2.x upgrade 1.x strategy
Posted by "lburgazzoli (via GitHub)" <gi...@apache.org>.
lburgazzoli commented on issue #4179:
URL: https://github.com/apache/camel-k/issues/4179#issuecomment-1492083608
I think that if we leave the KameltBinding CR we also must reconcile it so yeah they must co-exist.
How technically that's done that's something for which I don't have any strong opinion.
My only requirement would be that tools (gitops, monitoring, etc) must continue to work till the KameltBinding CRD gets removed.
--
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
[GitHub] [camel-k] squakez commented on issue #4179: Camel K 2.x upgrade 1.x strategy
Posted by "squakez (via GitHub)" <gi...@apache.org>.
squakez commented on issue #4179:
URL: https://github.com/apache/camel-k/issues/4179#issuecomment-1491962106
I'm trying to follow the tutorial here https://book.kubebuilder.io/multiversion-tutorial/conversion.html
However, we have some problem because the `v1alpha1` was made dependent of `v1`. Now, for conversion sake, we need `v1` to depend on `v1alpha1`, which makes a circular reference Go does not like at all.
--
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
[GitHub] [camel-k] lburgazzoli commented on issue #4179: Camel K 2.x upgrade 1.x strategy
Posted by "lburgazzoli (via GitHub)" <gi...@apache.org>.
lburgazzoli commented on issue #4179:
URL: https://github.com/apache/camel-k/issues/4179#issuecomment-1492010981
I think that must be an opt in settings and I would be really careful to do it by default as i.e. in a gitops scenario like with argocd, if the kameletbinding get translated to binding, then argocd would probably detect a drift and re-apply the kameletbinding resulting in a ping-pong scenario
--
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
[GitHub] [camel-k] squakez commented on issue #4179: Camel K 2.x upgrade 1.x strategy
Posted by "squakez (via GitHub)" <gi...@apache.org>.
squakez commented on issue #4179:
URL: https://github.com/apache/camel-k/issues/4179#issuecomment-1493997919
I'm working to maintain `KameletBindings` reconciliation loop. We have a cost of duplicating code but I guess we can survive with that until we remove the CR. However, we have another problem. The `KameletBinding` is meant to work with `v1alpha1.Kamelet`, which is also promoted to `v1.Kamelet`. That means that the reconciliation loop fails as it does not find the expected type, but the new `v1` one. A possible approach here would be to fallback to the new Kamelet version during the reconciliation loop.
--
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
[GitHub] [camel-k] squakez commented on issue #4179: Camel K 2.x upgrade 1.x strategy
Posted by "squakez (via GitHub)" <gi...@apache.org>.
squakez commented on issue #4179:
URL: https://github.com/apache/camel-k/issues/4179#issuecomment-1492102427
> I think that if we leave the KameltBinding CR we also must reconcile it so yeah they must co-exist.
>
> How technically that's done that's something for which I don't have any strong opinion. My only requirement would be that tools (gitops, monitoring, etc) must continue to work till the KameltBinding CRD gets removed.
Okey, that was something I did not take in consideration. I see your point, but this is adding some complexity. Friday afternoon is not very good for designing things... I'll have some thought next week :)
--
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
[GitHub] [camel-k] squakez closed issue #4179: Camel K 2.x upgrade 1.x strategy
Posted by "squakez (via GitHub)" <gi...@apache.org>.
squakez closed issue #4179: Camel K 2.x upgrade 1.x strategy
URL: https://github.com/apache/camel-k/issues/4179
--
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
[GitHub] [camel-k] claudio4j commented on issue #4179: Camel K 2.x upgrade 1.x strategy
Posted by "claudio4j (via GitHub)" <gi...@apache.org>.
claudio4j commented on issue #4179:
URL: https://github.com/apache/camel-k/issues/4179#issuecomment-1490427681
It is interesting [how syndesis upgraded to new versions](https://github.com/syndesisio/syndesis/blob/1.15.x/install/operator/pkg/syndesis/versions/versions.go).
It migrates the old custom resources to new one. This way the apis can be upgrade from v1alpha -> v1beta -> v1 -> ...
--
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
[GitHub] [camel-k] squakez commented on issue #4179: Camel K 2.x upgrade 1.x strategy
Posted by "squakez (via GitHub)" <gi...@apache.org>.
squakez commented on issue #4179:
URL: https://github.com/apache/camel-k/issues/4179#issuecomment-1490434976
> It is interesting [how syndesis upgraded to new versions](https://github.com/syndesisio/syndesis/blob/1.15.x/install/operator/pkg/syndesis/versions/versions.go).
>
> It migrates the old custom resources to new one. This way the apis can be upgrade from v1alpha -> v1beta -> v1 -> ...
Thanks for the link, was not aware of that in Syndesis. I'm right now looking to solve this problem as it finally we'll need to upgrade the `KameletBinding` to `Binding` CR type. However, I'm looking at https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#webhook-conversion which looks to be the official way in order to handle the conversion. In our case it should be easy enough as we only need to change the name of the resource.
--
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
[GitHub] [camel-k] squakez commented on issue #4179: Camel K 2.x upgrade 1.x strategy
Posted by "squakez (via GitHub)" <gi...@apache.org>.
squakez commented on issue #4179:
URL: https://github.com/apache/camel-k/issues/4179#issuecomment-1523175123
Upgrade strategy defined in https://camel.apache.org/camel-k/next/contributing/upgrade.html
--
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
[GitHub] [camel-k] squakez commented on issue #4179: Camel K 2.x upgrade 1.x strategy
Posted by "squakez (via GitHub)" <gi...@apache.org>.
squakez commented on issue #4179:
URL: https://github.com/apache/camel-k/issues/4179#issuecomment-1492069762
> I think that must be an opt in settings and I would be really careful to do it by default as i.e. in a gitops scenario like with argocd, if the kameletbinding get translated to binding, then argocd would probably detect a drift and re-apply the kameletbinding resulting in a ping-pong scenario
Yes, my main concern is to avoid such kind of situations as we don't know how exactly those resources are deployed to the cluster. Right now, with no conversion in place, what it happens in an upgrade scenario is that a KameletBinding is no longer reconciled when we move to Camel K V2. The resource will sit there with nobody reconciling it. Another possibility is to delegate such a conversion on the `kamel rebuild`, or definitely let the user to manually convert to a Binding when he wants to upgrade.
--
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
[GitHub] [camel-k] squakez commented on issue #4179: Camel K 2.x upgrade 1.x strategy
Posted by "squakez (via GitHub)" <gi...@apache.org>.
squakez commented on issue #4179:
URL: https://github.com/apache/camel-k/issues/4179#issuecomment-1492076483
> if the kameletbinding get translated to binding, then argocd would probably detect a drift and re-apply the kameletbinding resulting in a ping-pong scenario
Do you think it would help if both `KameletBinding` and `Binding` will coexist? I mean, whoever is creating a `KameletBinding` will still see that resource, but internally Camel K would use a `Binding`.
--
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
[GitHub] [camel-k] squakez commented on issue #4179: Camel K 2.x upgrade 1.x strategy
Posted by "squakez (via GitHub)" <gi...@apache.org>.
squakez commented on issue #4179:
URL: https://github.com/apache/camel-k/issues/4179#issuecomment-1491997521
I'm thinking that in our case we may take care to convert them on the fly, during a the first reconciliation loop. Basically, when a `KameletBinding` would be reconciled for the first time (after an upgrade to Camel K 2.0) we may convert it to a `Binding` (taking care not to alter the status and avoid retriggering an Integration). @lburgazzoli @astefanutti wdyt?
--
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