Routing errors propagation #385
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add string field .status.message to devworkspaceroutings to allow the devworkspacerouting reconciler to propagate error messages up to the owner DevWorkspace. Also add a few printColumns to print useful information about the DevWorkspaceRouting: - The owner's DevWorkspaceId - The current phase - The current status.message Signed-off-by: Angel Misevski <amisevsk@redhat.com>
Signed-off-by: Angel Misevski <amisevsk@redhat.com>
When a DevWorkspaceRouting enters the failed phase, propagate the message in `routing.status.message` to the DevWorkspace as a failure reason. Signed-off-by: Angel Misevski <amisevsk@redhat.com>
Propagate messages (where appropriate) from DevWorkspaceRouting to DevWorkspaces (e.g. "preparing services/ingresses/routes"). Note that for a typical successful startup, these messages will never be reconciled to the DevWorkspace (as the routing enters the ready state too quickly) but could help diagnose issues if a particular step occurs slowly. Also change how status for DevWorkspaceRoutings is synced to ensure that "Preparing" phase is entered while resources are being created. Signed-off-by: Angel Misevski <amisevsk@redhat.com>
sleshchenko
approved these changes
Apr 15, 2021
...t/openshift/objects/devworkspaceroutings.controller.devfile.io.CustomResourceDefinition.yaml
Show resolved
Hide resolved
metlos
approved these changes
Apr 16, 2021
|
/test v7-devworkspaces-operator-e2e |
JPinkney
approved these changes
Apr 16, 2021
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: amisevsk, JPinkney, metlos, sleshchenko The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Adds a string field
.status.messageto DevWorkspaceRoutings, and uses this value in place of"preparing networking"in DevWorkspaces that are waiting for routing to be ready. This means that user-readable failure reasons can be set in DevWorkspaceRoutings and are automatically propagated to the DevWorkspace status.Also adds printColumns to DevWorkspaceRoutings to improve readability for short output:
Commit messages should be clear for what each commit adds. Note that I've also added propagating messages from dwr to dw status even when the dwr is not failed, but since a the dwr is ready so quickly in normal usage the message never reaches the DevWorkspace's status, so we never see
Preparing [services|routes|ingresses]. This might still be useful if e.g. there is an issue applying resources, but might also make tracking progress harder (since the messages may or may not appear)What issues does this PR fix or reference?
Closes eclipse-che/che#17455
Is it tested? How?
Easiest to test on Kubernetes as otherwise all routingClasses are valid and the default
dwrreconciler cannot fail:{ cat <<EOF | kubectl apply -f - kind: DevWorkspace apiVersion: workspace.devfile.io/v1alpha2 metadata: name: theia-next spec: started: true routingClass: cluster-tls template: components: - name: theia plugin: uri: https://che-plugin-registry-main.surge.sh/v3/plugins/eclipse/che-theia/next/devfile.yaml EOF } && kubectl get dw -wOutput: