search

migtools / crane-ui-plugin

OpenShift Dynamic Plugin for Crane UI
1 stars 11 forks source link

No way to represent a success with warnings scenario at present #96

Open jmontleon opened 2 years ago

jmontleon commented 2 years ago

There are some cases where a migration might fail to create some resources, but otherwise the migration succeeded.

One scenario we're currently aware of is migrating from a DevSandbox instance to your own OpenShift cluster as a non-admin. In this scenario you will be able to read some resources that can only be created as a cluster admin, such as limitranges.

As a namespace admin on both clusters you will be able to read and export the limitrange, but unable to create it on the destination.

This doesn't affect the application from migrating or running, but at present will cause the pipeline to fail.

In MTC we had the notion of a success with warnings, which would have covered the case where some resources could not be recreated.

github-actions[bot] commented 2 years ago

This issue is currently awaiting triage. If contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance. The triage/accepted label can be added by org members by writing /triage accepted in a comment.

eriknelson commented 2 years ago

/priority critical /type feature /triage accepted

github-actions[bot] commented 2 years ago

This issue synced with: https://issues.redhat.com/browse/MTRHO-91

mturley commented 2 years ago

Do we know if this is something supported by the existing Pipelines UI / Tekton status reporting? As it stands our plugin doesn't do any kind of progress/status reporting (just kicks the user over to the PipelineRun page) and with the new management page I'm adding in #88 the goal is to only very minimally report status (ideally reusing code from the Pipelines UI) and link to that PipelineRun page for detailed status.

eriknelson commented 2 years ago

@mturley I don't know if pipelines has any real support for this. We should check with that team perhaps in slack and update with the answer here.

shawn-hurley commented 2 years ago

If there is something that a user can not do, it should fail, and the user should make a choice.

We should have transforms/options for them to re-run if they just want to remove the objects that failed, but I don't think that hiding this information should be the goal.