-
Notifications
You must be signed in to change notification settings - Fork 178
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
Disabling a custom Notebook Image from view makes its Workbenches display an Unknown image #1520
Comments
cc @harshad16 We are talking about how we can fix the naming of Our solution today looks to be the Dashboard just tries a little harder to hold onto the name and give a better idea of it's still existence. Does beg the question, could we keep tags for a long while around being pulled but no longer selected. The UI can show that we have moved away from that image tag, but your notebooks would still spawn with an "unavailable" image stream tag. |
That being said -- obv deleting the image (in this case our BYON images -- not the OOTB ones) should prevent it from spinning up I imagine. Because if you deleted the image stream from the cluster, I think it is fair to not allow it to spin up. |
At least for the image digest reference that is possible. When deleting or modifying a tag (the tag, not from.name of it) in the imagestream spec, the old tag with the image reference is persisted in the imagestream status section. So notebooks keep running (already spun-up workbenches in dashboard lingo). If the entire imagestream (image in dashboard lingo) is not deleted, then the name from that annotation in imagestream could be put into a Notebook CR annotation and then persisted that way. All tag details (software package versions and so on) are lost, though, in case an imagestream tag changes. I am talking about my PR-800 approach here, have tried it out. Yes, deleting the imagestream / image (imagestream mods) between selection and startup keeps it from spinning up anew, but the already running notebooks are not affected, they run either with their internal docker image registry reference still there (unless pruned) or with the external docker image reference in sha256 format that then links via a different mechanism to the enterprise docker registry (on a scenario where internal docker registry is not used).
Yeah, one cannot delete or modify the OOTB imagestreams, they come with odh-manifests and are synced up by ODH operator. The list of images and tags available in dashboard, if it gets refreshed in real-time, we will never have an issue with a user selecting an image whose imagestream or specific version / tag has already been deleted or disabled. |
Great idea about changing imagePullPolicy to "IfNotPresent". Also, it would be good if BYON imagestreams always had sha256 digest notation in tag.from.name, regardless of whether a user provides a BYON image url with a tag or with a digest. If that lookup to digest is not possible in odh dashboard code, that is not so bad. Because the image change trigger annotation way of looking up the container image value for a given imagestream name and tag always resolves the image-field on the container to sha256 digest notation, even if tag.from.name string / url is in tag-format. If the user provided a digest format image url, then there'd have to open an input textbox allowing the user to set the wished tag (of the imagestream). Have a good weekend :-) |
@andrewballantyne , i feel , we could probably do from the notebook itself, i m not sure, how we can do this. |
kinda like a mark-for-deletion of a given tag, yes, not actually deleting the tag from spec at first. And then in a different GUI, once it is certain no notebooks running on that tag are there anymore, delete the marked-for-deletion tag at a later point in time. Good idea. |
I'm going to move this to the Dashboard repo. I suspect the solution will be handled by the "store the notebook name" efforts we have already talked about (linked in an earlier chat) -- at least it won't be called "Unknown" at the worse case. I'll leave it open in case the solution to the other issue doesn't quite solve this ideally. |
@Gkrumbach07 Can you check if your PR #1872 could also resolve this issue? |
@erwangranger does this fix the bug you described? |
@kywalker-rh @xianli123 thoughts on the double brackets 🤔 |
@Gkrumbach07 , yes, this is definitely better than the existing behavior. So, I say, ship it, as-is. But if we wanted to then open another quick issue to make this even better, I would say the following should be its description.
If there is time to take some of this into account without adding delay to the resolution, great. If not, the rest can wait. |
Maybe not in time for this sprint, because UX will need to go over the proposed changes. UX Context@kywalker-rh, @xianli123, @vconzola This proposed change is a continuation to #1370 where we added the wording
UX let me know if you have follow up questions @erwangranger Does this capture what you were hoping to see? |
It does, yes. Thanks. |
@Gkrumbach07 and @erwangranger... @xianli123 and @vconzola are out until next week. I would typically defer to them, but in order move this along a bit in the meantime, I agree with the changes for the first and the third bullet. The second one will take some exploration to figure out the best place to surface that text. I support you moving forward with all the changes except adding the additional wording.
@andrewballantyne It is a little strange, maybe a - deprecated would be more appropriate. I didn't realize we had more brackets in that field. |
@Gkrumbach07 give Also I think we can combine these two issues together and merge your PR for both. If we need additional cleanup, we can log those separate. I think this PR context is a lot overlapping with your PR efforts. |
@kywalker-rh why are we trying to work within text by using |
@Gkrumbach07 mock it up 🙂 |
I like the red icon thing. (is that what PF label is?) Everything else looks like it could be part of the image name. Which would also be problematic in case someone actually renames the image with |
@erwangranger Yes this is the docs for it. I also made the label We can also switch up the colors and make deprecated and disabled different colors (grey and red) |
Thanks @Gkrumbach07... I really like the label, thank you for proposing it! I want to check on colors, red is definitely very obvious, but that may be good or bad. I'm going to check with the rest of the UX team and respond later today. |
Hi @Gkrumbach07 @kywalker-rh @andrewballantyne . I've looked through this issue and all discussions. I prefer labels to double brackets. As for the wording, I think " With regard to the label colors, PF mentioned that:
We usually use grey labels in our design to indicate the In addition, I am not sure if it's possible or necessary to add a popover as shown below to tell users why the image is in that status. (The content of the popover is a rough placeholder.) What do you think? |
This is the design based on our discussion in this issue and Slack thread. Please take a look. If there are any suggestions, please leave your comments. To summarize the solution:
|
Completed by #1872 |
Status
Might be resolved by:
If not, this ticket will need attention.
After disabling a custom image, it's still visible in the workbench, but its image is "unknown".
To Reproduce:
additional notes:
The text was updated successfully, but these errors were encountered: