You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by GitBox <gi...@apache.org> on 2021/01/25 09:35:55 UTC
[GitHub] [camel-k] lburgazzoli opened a new issue #1943: operator: option lo limiti CRs the operator should handle
lburgazzoli opened a new issue #1943:
URL: https://github.com/apache/camel-k/issues/1943
We should be able to restrict what CRs a camel-k operator should handle, as example, we can add a label like `camel.apache.org/operator.id` to each CR:
```yaml
apiVersion: camel.apache.org/foo
kind: bar
metadat
labels:
camel.apache.org/operator.id: "operator-1"
```
The `operator.id` should also be used to acquire the operator lock.
Note:
- We'd need to amend the kamel commands to eventually take into account such label
- We'd need to introduce a new command to move CR between operators
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] astefanutti commented on issue #1943: operator: option to limit CRs the operator should handle
Posted by GitBox <gi...@apache.org>.
astefanutti commented on issue #1943:
URL: https://github.com/apache/camel-k/issues/1943#issuecomment-855958653
> @astefanutti we should also take into account the IntegrationPlatform CR i.e. if multiple operators are installed in the same namespace, it should be possible to have multiple instances of the IntegrationPlatform labeled according so only the relevant operator would use it (note: we may think about naming the maven settings config map after the selector label) .
Right, _scoping_ IntegrationPlatform should be supported in addition to _scoping_ Integration. actually, I think _scoping_ must be implemented for any kind of resources being watched / managed by the operator, like IntegrationKit, Build, ... Even for environments that do not leverage the builder, I think it makes sense to implement a generic _scoping_ mechanism.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] lburgazzoli commented on issue #1943: operator: option to limit CRs the operator should handle
Posted by GitBox <gi...@apache.org>.
lburgazzoli commented on issue #1943:
URL: https://github.com/apache/camel-k/issues/1943#issuecomment-848688252
@astefanutti we should also take into account the `IntegrationPlatform` CR i.e. if multiple operators are installed in the same namespace, it should be possible to have multiple instances of the `IntegrationPlatform` labeled according so only the relevant operator would use it (note: we may think about naming the maven settings config map after the selector label) .
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] heiko-braun commented on issue #1943: operator: option to limit CRs the operator should handle
Posted by GitBox <gi...@apache.org>.
heiko-braun commented on issue #1943:
URL: https://github.com/apache/camel-k/issues/1943#issuecomment-822247796
Is the `camel.apache.org/operator.id` used to describe an instance of an operator?
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] astefanutti commented on issue #1943: operator: option to limit CRs the operator should handle
Posted by GitBox <gi...@apache.org>.
astefanutti commented on issue #1943:
URL: https://github.com/apache/camel-k/issues/1943#issuecomment-766698032
Ideally, these labels should be taken into account by the controller-runtime informer that watches for Integration resources, to filter sever-side, so that the corresponding operator does not filter client-side and cache the out-of-scope Integrations, so that the solution scales nicely.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] heiko-braun commented on issue #1943: operator: option to limit CRs the operator should handle
Posted by GitBox <gi...@apache.org>.
heiko-braun commented on issue #1943:
URL: https://github.com/apache/camel-k/issues/1943#issuecomment-822248589
+1 on the lease resource for managing locks.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] astefanutti edited a comment on issue #1943: operator: option to limit CRs the operator should handle
Posted by GitBox <gi...@apache.org>.
astefanutti edited a comment on issue #1943:
URL: https://github.com/apache/camel-k/issues/1943#issuecomment-766722287
> Ideally, these labels should be taken into account by the controller-runtime informer that watches for Integration resources, to filter sever-side, so that the corresponding operator does not filter client-side and cache the out-of-scope Integrations, so that the solution scales nicely.
It seems like server-side filtering is not yet possible with controller-runtime: kubernetes-sigs/controller-runtime#244.
We can go for a client-side predicate in the meantime.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] heiko-braun edited a comment on issue #1943: operator: option to limit CRs the operator should handle
Posted by GitBox <gi...@apache.org>.
heiko-braun edited a comment on issue #1943:
URL: https://github.com/apache/camel-k/issues/1943#issuecomment-822248589
+1 on the lease resource for managing locks.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] astefanutti commented on issue #1943: operator: option to limit CRs the operator should handle
Posted by GitBox <gi...@apache.org>.
astefanutti commented on issue #1943:
URL: https://github.com/apache/camel-k/issues/1943#issuecomment-822246883
Right. As we are introducing a mechanism where multiple operators can concurrently manage the same resources, a _locking_ mechanism is necessary. More generally to the rolling upgrade use-case, that mechanism would make sure that only a single operator manages the same resource at a single point in time. That would prevent issues where the label selectors for multiple operators intersect.
Now on how to implement that _locking_ mechanism, I think we could reuse the approach used for locking by multiple replicas of the same operator, that is with a Lease resource, but owned by the Integration. The Lease resource seems the preferred mechanism (by client-go and controller-runtime), and handle use cases such as renewing and deadlining nicely. It would also be another extension of the locking implementation already in place for managing HA of the operator replicas.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] astefanutti commented on issue #1943: operator: option to limit CRs the operator should handle
Posted by GitBox <gi...@apache.org>.
astefanutti commented on issue #1943:
URL: https://github.com/apache/camel-k/issues/1943#issuecomment-766722287
> Ideally, these labels should be taken into account by the controller-runtime informer that watches for Integration resources, to filter sever-side, so that the corresponding operator does not filter client-side and cache the out-of-scope Integrations, so that the solution scales nicely.
It seems like it's not yet possible with controller-runtime: kubernetes-sigs/controller-runtime#244.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] astefanutti commented on issue #1943: operator: option to limit CRs the operator should handle
Posted by GitBox <gi...@apache.org>.
astefanutti commented on issue #1943:
URL: https://github.com/apache/camel-k/issues/1943#issuecomment-766698032
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] lburgazzoli commented on issue #1943: operator: option to limit CRs the operator should handle
Posted by GitBox <gi...@apache.org>.
lburgazzoli commented on issue #1943:
URL: https://github.com/apache/camel-k/issues/1943#issuecomment-822170473
One of the use case where is feature can be useful is to implement "rolling upgrade" of the camel-k operator where you have multiple running version of the camel-k operator and you want to move integrations from one operator to the another by steps.
The simplest approach is to change the label i.e. from `camel.apache.org/operator.id: "operator-1"` to `camel.apache.org/operator.id: "operator-2"` however this may not be enough as "operator-1" may be performing some work and changing the label may leave the integration in a inconsistent state so we may need to introduce a camel-k level `finalizer` concept to let the operator currently owning a resource to gracefully release a resource and moving it to the target operator.
@astefanutti @nicolaferraro what do you think ?
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] nicolaferraro closed issue #1943: operator: option to limit CRs the operator should handle
Posted by GitBox <gi...@apache.org>.
nicolaferraro closed issue #1943:
URL: https://github.com/apache/camel-k/issues/1943
--
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] astefanutti edited a comment on issue #1943: operator: option to limit CRs the operator should handle
Posted by GitBox <gi...@apache.org>.
astefanutti edited a comment on issue #1943:
URL: https://github.com/apache/camel-k/issues/1943#issuecomment-766722287
> Ideally, these labels should be taken into account by the controller-runtime informer that watches for Integration resources, to filter sever-side, so that the corresponding operator does not filter client-side and cache the out-of-scope Integrations, so that the solution scales nicely.
It seems like server-side filtering is not yet possible with controller-runtime: kubernetes-sigs/controller-runtime#244.
We can go for a client-side predicate in the meantime.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] astefanutti commented on issue #1943: operator: option to limit CRs the operator should handle
Posted by GitBox <gi...@apache.org>.
astefanutti commented on issue #1943:
URL: https://github.com/apache/camel-k/issues/1943#issuecomment-855966381
Selectors support has been added to k8s informers into the latest version of controller-runtime: kubernetes-sigs/controller-runtime#1435.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] astefanutti edited a comment on issue #1943: operator: option to limit CRs the operator should handle
Posted by GitBox <gi...@apache.org>.
astefanutti edited a comment on issue #1943:
URL: https://github.com/apache/camel-k/issues/1943#issuecomment-822246883
Right. As we are introducing a mechanism where multiple operators can concurrently manage the same resources, a _locking_ mechanism is necessary. More generally to the rolling upgrade use-case, that mechanism would make sure that only a single operator manages the same resource at a single point in time. That would prevent issues where the label selectors for multiple operators intersect.
Now on how to implement that _locking_ mechanism, I think we could reuse the approach used for locking by multiple replicas of the same operator, that is with a Lease resource, but owned by the Integration. The Lease resource seems the preferred mechanism (by client-go and controller-runtime), and handle use cases such as renewing and deadlining nicely. It would also be an extension of the locking implementation already in place for managing HA of the operator replicas.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] heiko-braun edited a comment on issue #1943: operator: option to limit CRs the operator should handle
Posted by GitBox <gi...@apache.org>.
heiko-braun edited a comment on issue #1943:
URL: https://github.com/apache/camel-k/issues/1943#issuecomment-822248589
+1 on the lease resource for managing locks. Has anyone played with https://github.com/jrhouston/k8slock yet?
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org