-
Notifications
You must be signed in to change notification settings - Fork 63
fix: Set workspace warning if error occurs when resolving external DWOC #925
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.
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
fix: Set workspace warning if error occurs when resolving external DWOC #925
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: AObuchow, ibuziuk The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
} else { | ||
configResolveStatus.setConditionFalse(conditions.DevWorkspaceWarning, "External DevWorkspaceOperatorConfig successfully resolved") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if setting the condition false here is correct -- what this is saying is that there are no warnings (general) for the workspace, not that there's no issue with the config. I think it can be left undefined as it is for other ones (maybe in the future the last thing we do is explicitly set it false at the very end?) -- that way the warning condition doesn't show up at all until there's a warning.
@@ -123,10 +123,13 @@ func (r *DevWorkspaceReconciler) Reconcile(ctx context.Context, req ctrl.Request | |||
return reconcile.Result{}, err | |||
} | |||
|
|||
configResolveStatus := &workspaceConditions{} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could instead init the reconcileStatus struct here:
reconcileStatus := currentStatus{}
// maybe, if warning:
reconcileStatus.setConditionTrue(conditions.DevWorkspaceWarning, fmt.Sprint("Error applying external DevWorkspace-Operator configuration: ", err.Error()))
and potentially set the warning condition in it if necessary. Then later, at lines 214/215
- reconcileStatus := currentStatus{phase: dw.DevWorkspaceStatusStarting}
+ reconcileStatus.phase = dw.DevWorkspaceStatusStarting
reconcileStatus.setConditionTrue(conditions.Started, "DevWorkspace is starting")
// Notify if error occured when resolving external DevWorkspaceOperatorConfig, as long as no other active warnings are present | ||
if condition, ok := reconcileStatus.conditions[conditions.DevWorkspaceWarning]; !ok || condition.Status == corev1.ConditionFalse { | ||
reconcileStatus.setCondition(conditions.DevWorkspaceWarning, configResolveStatus.conditions[conditions.DevWorkspaceWarning]) | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is somewhat awkward placement for this -- if we want it here to not lose e.g. a warning in flattening, then it should be even later in the function. What if a later step wants to add a warning?
See the note about initializing reconcileStatus earlier, that may be a cleaner option. Note that for now, setConditionTrue
overwrites the condition if it's already present, so taking this approach would have the same functionality.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if a later step wants to add a warning?
Good point 👍
Note that for now, setConditionTrue overwrites the condition if it's already present, so taking this approach would have the same functionality.
I think the issue (with setting the warning condition earlier) then becomes that the config resolution warning will be suppressed by the no-warning-case when flattening.
Perhaps the workspace conditions need to be modified a bit to allow for enabling/disabling different types of conditions with more granularity (eg. allow for a flattening warning condition set to false, while having a config resolution warning set to true)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah that's a good point... I might err on the side of removing that line in the flatten flow and never setting the warning condition as false 🤷
Up to you. I've got a TODO on my backlog somewhere to improve warnings handling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though it's not nice, I'm also +1 for removing that line from the flattening flow, for the time being.
I can create another issue to improve warnings handling, and I'm down to work on this whenever :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't realize the warning will get unset if no warnings occurred by the end of the reconcile function - so this isn't as big of a deal as I had initially thought
New changes are detected. LGTM label has been removed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AObuchow looks like some of the commits are missing Signed-off-by:
, could you possibly squash in one?
Fix devfile#921 Signed-off-by: Andrew Obuchowicz <[email protected]>
Signed-off-by: Andrew Obuchowicz <[email protected]>
e1bc7b5
to
1f87eb9
Compare
What does this PR do?
Sets the workspace status to warning if an issue occurs while resolving the external DWOC (specified in the optional
controller.devfile.io/devworkspace-config
workspace attribute).The warning will not appear if other active warnings exist for the workspace (eg. if there was an error during the flattening process of a workspace). This was an opinionated decision, as I think other warnings may have higher priority/urgency compared to not being able to resolve the external DWOC. I can change this if desired :)
What issues does this PR fix or reference?
Fix #921
Is it tested? How?
devworkspace-controller
namespace, you should see that warnings are present:[aobuchow@fedora samples]$ kubectl get dw -n $NAMESPACE -w NAME DEVWORKSPACE ID PHASE INFO theia-next-external-dwoc workspace7015525656304d3d Running [warnings present] https://workspace7015525656304d3d-theia-3100.192.168.49.2.nip.io/
A
kubectl describe
should list in the Status that the external DWOC was not found:kubectl describe dw theia-next-external-dwoc -n $NAMESPACE
default
namespace:[aobuchow@fedora samples]$ kubectl get dw -n $NAMESPACE -w NAME DEVWORKSPACE ID PHASE INFO theia-next-external-dwoc workspace7015525656304d3d Running https://workspace7015525656304d3d-theia-3100.192.168.49.2.nip.io/
kubectl describe dw theia-next-external-dwoc -n $NAMESPACE
:PR Checklist
/test v8-devworkspace-operator-e2e, v8-che-happy-path
to trigger)v8-devworkspace-operator-e2e
: DevWorkspace e2e testv8-che-happy-path
: Happy path for verification integration with Che