Continue resource handling after being cancelled before #221
Comments
lucas-koehler
changed the title
lucas-koehler
added a commit
that referenced
this issue
Aug 31, 2023
Adds support to the operator to handle AppDefinitions that are in HANDLING state. This happens when the operator was unexpectedly shut down while handling the AppDefinition before. No logic changes in creating Kubernetes resources are necessary because the handling was already idempotent. Contributed on behalf of STMicroelectronics
lucas-koehler
added a commit
that referenced
this issue
Aug 31, 2023
The Workspace handling already makes sure steps are not executed twice. Thus, we can simply try handling again Contributed on behalf of STMicroelectronics
|
This issue is stale because it has been open for 180 days with no activity. |
|
Keep open |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Follow up of #200.
When the operator starts handling a CR (i.e. AppDefinition, Session, Workspace), it marks the resource as
HANDLING. If the operator is killed (e.g. by Kubernetes due to resources or an update), the resource is never set toHANDLED.Currently, resources in
HANDLINGare never processed again to prevent handling resources that caused unexpected crashes,However, unexpected crashes can be caught (and should already after #200).
Describe the solution you'd like
When a resource with status
HANDLINGis processed again, the operator needs to consider that encountering an already completed step does not mean that handling was finished. Instead, the operator should only execute the missing steps.Describe alternatives you've considered
None, eventually we need to be safe against operators being stopped while handling a resource.
Cluster provider
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: