Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Idler should support scale sub resources #343

Closed
christophd opened this issue Feb 25, 2022 · 0 comments · Fixed by #378
Closed

Idler should support scale sub resources #343

christophd opened this issue Feb 25, 2022 · 0 comments · Fixed by #378

Comments

@christophd
Copy link
Contributor

The idler currently works on K8s built in resources such as Pods, Deployments and ReplicaSets to perform kill/scale-to-zero operations on long running user workloads.

Yet a user workload's custom resource may also control the replicas via scale sub resource (https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).

In this case scaling deployments and replica sets to zero won't have any effect on the replicas as the custom resource controller will immediately bring back the replicas. The idler will then kill pods and the scale sub resource brings them back immediately.

A sample of such a workload using the scale sub resource is the Camel K integration custom resource.
https://github.com/apache/camel-k/blob/main/config/crd/bases/camel.apache.org_integrations.yaml#L5911

In case the deployment is owned by a custom resource the idler should also support the scale sub resource to make sure that the user workload is stopped properly.
christophd added a commit to christophd/member-operator that referenced this issue Sep 19, 2022
@christophd
fix(codeready-toolchain#343): Add support for scale sub resource
2793215 
Update the idler component to also support deployments managed by scale sub resources. In case a deployment is owned by a custom resource that holds a scale sub resource the idler will patch the scale resource instead of the deployment directly.

This makes sure that the idler is able to terminate deployments owned by scale resources, too.

At the moment ths is being used by Camel K workloads such as Integration and KameletBinding custom resources.
christophd added a commit to christophd/member-operator that referenced this issue Sep 20, 2022
@christophd
fix(codeready-toolchain#343): Add support for scale sub resource
feb4a19 
Update the idler component to also support deployments managed by scale sub resources. In case a deployment is owned by a custom resource that holds a scale sub resource the idler will patch the scale resource instead of the deployment directly.

This makes sure that the idler is able to terminate deployments owned by scale resources, too.

At the moment ths is being used by Camel K workloads such as Integration and KameletBinding custom resources.
christophd added a commit to christophd/member-operator that referenced this issue Sep 20, 2022
@christophd
fix(codeready-toolchain#343): Add support for scale subresource
b6e440e 
Update the idler component to also support deployments managed by scale subresource. In case a deployment is owned by a custom resource that holds a scale subresource the idler will patch the scale resource instead of the deployment directly.

This makes sure that the idler is able to terminate deployments owned by scale resources, too.

This is being used by Camel K workloads such as Integration and KameletBinding custom resources.
@christophd christophd mentioned this issue Sep 20, 2022
Merged
alexeykazakov added a commit that referenced this issue Sep 21, 2022
@christophd @alexeykazakov
fix(#343): Add support for scale subresource (#378)
4843bd6 
* fix(#343): Add support for scale subresource

Update the idler component to also support deployments managed by scale subresource. In case a deployment is owned by a custom resource that holds a scale subresource the idler will patch the scale resource instead of the deployment directly.

This makes sure that the idler is able to terminate deployments owned by scale resources, too.

This is being used by Camel K workloads such as Integration and KameletBinding custom resources.

* Fix linter issues

Co-authored-by: Alexey Kazakov <alkazako@redhat.com>
christophd added a commit to christophd/member-operator that referenced this issue Oct 26, 2022
@christophd
fix(codeready-toolchain#343): Add permissions to scale Camel K resources
842baab 
Allow controller manager to scale Camel K Integration and KameletBinding custom resources on the cluster

Signed-off-by: Christoph Deppisch <cdeppisch@redhat.com>
openshift-merge-robot pushed a commit that referenced this issue Oct 27, 2022
@christophd
fix(#343): Add permissions to scale Camel K resources (#387)
85f6330 
Allow controller manager to scale Camel K Integration and KameletBinding custom resources on the cluster

Signed-off-by: Christoph Deppisch <cdeppisch@redhat.com>

Signed-off-by: Christoph Deppisch <cdeppisch@redhat.com>
christophd added a commit to christophd/member-operator that referenced this issue Oct 27, 2022
@christophd
fix(codeready-toolchain#343): Support scale resources that do not hav…
deceab7 
…e specReplicasPath field set

The replicas field defined in specReplicasPath may be optional in the custom resource. In this case getting the scale resource fails with internal server error. In this case try to set a new scale resource with replicas=0. This fixes idling of Camel K integrations and bindings that do not explicitly have a `spec.replicas` field set and default to replicas=1.

Signed-off-by: Christoph Deppisch <cdeppisch@redhat.com>
christophd added a commit to christophd/member-operator that referenced this issue Oct 28, 2022
@christophd
fix(codeready-toolchain#343): Support scale resources that do not hav…
4318d25 
…e specReplicasPath field set

The replicas field defined in specReplicasPath may be optional in the custom resource. In this case getting the scale resource fails with internal server error. In this case try to set a new scale resource with replicas=0. This fixes idling of Camel K integrations and bindings that do not explicitly have a `spec.replicas` field set and default to replicas=1.

Signed-off-by: Christoph Deppisch <cdeppisch@redhat.com>
christophd added a commit to christophd/member-operator that referenced this issue Oct 28, 2022
@christophd
fix(codeready-toolchain#343): Support scale resources that do not hav…
10ca8ec 
…e specReplicasPath field set

The replicas field defined in specReplicasPath may be optional in the custom resource. In this case getting the scale resource fails with internal server error. In this case try to set a new scale resource with replicas=0. This fixes idling of Camel K integrations and bindings that do not explicitly have a `spec.replicas` field set and default to replicas=1.

Signed-off-by: Christoph Deppisch <cdeppisch@redhat.com>
christophd added a commit to christophd/member-operator that referenced this issue Oct 28, 2022
@christophd
fix(codeready-toolchain#343): Support scale resources that do not hav…
d7d1d02 
…e specReplicasPath field set

The replicas field defined in specReplicasPath may be optional in the custom resource. In this case getting the scale resource fails with internal server error. In this case try to set a new scale resource with replicas=0. This fixes idling of Camel K integrations and bindings that do not explicitly have a `spec.replicas` field set and default to replicas=1.

Signed-off-by: Christoph Deppisch <cdeppisch@redhat.com>
christophd added a commit to christophd/member-operator that referenced this issue Oct 28, 2022
@christophd
fix(codeready-toolchain#343): Support scale resources that do not hav…
1101c24 
…e specReplicasPath field set

The replicas field defined in specReplicasPath may be optional in the custom resource. In this case getting the scale resource fails with internal server error. In this case try to set a new scale resource with replicas=0. This fixes idling of Camel K integrations and bindings that do not explicitly have a `spec.replicas` field set and default to replicas=1.

Signed-off-by: Christoph Deppisch <cdeppisch@redhat.com>
alexeykazakov pushed a commit that referenced this issue Oct 29, 2022
@christophd
fix(#343): Support scale resources that do not have specReplicasPath …
ef9037c 
…field set (#388)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(#343): Add support for scale subresource christophd/member-operator
1 participant
@christophd