-
Notifications
You must be signed in to change notification settings - Fork 6
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
Update Notebooks components #498
Conversation
d85b6bf
to
57df017
Compare
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.
Very nice! I have two minor changes in the messages.
57df017
to
1933925
Compare
I have updated the text in the 2 messages and aligned all |
The servers endpoint used for notebooks interaction has slightly changed and the server status information are different. This refactor handles the new information properly and remove duplicate codes from Project pages BREAKING CHANGE: different status indication for notebook pages, according to renku-notebooks#177 fix #494
1933925
to
00af877
Compare
I realized I forgot to move the project id filtering logic from "Projects" pages to the "notebook-servers" API. Now it has been updated and re-deployed to https://lorenzotest.dev.renku.ch This logic could be simplified in the future using the new notebook service API from SwissDataScienceCenter/renku-notebooks#188 |
#498 introduced a bug in Notebook.state since the polling actions are never interrupted when needed -- e.g. when the query to the servers endpoint is skipped or the list of servers is still updating
This is the UI adaptation to handle the API responses from SwissDataScienceCenter/renku-notebooks#177 (requires also SwissDataScienceCenter/renku-notebooks#187)
A preview is available here: https://lorenzotest.dev.renku.ch
At the moment we have lost the distinction between "starting" and "stopping" servers, we only mark them as "pending". This may be acceptable, but the UI shows that after the stop API is invoked, the server will still be considered "ready" for a while.
An idea to improve this could be using an extra annotation to save in the pod the information that the stop command has been invoked by the user, then returning it in the
/servers
endpoint in the status.