-
Task
-
Resolution: Done
-
Critical
-
None
-
None
-
3
-
False
-
False
-
No
-
-
-
-
-
-
No
-
Stories have been submitted via the Epic.
-
No
-
Pending
-
None
-
-
MODH Sprint 20, MODH Sprint 21
As a user, I want to ensure that when Python libraries & packages are updated to newer versions, the updates don't break my notebooks.
Red Hat will periodically update supported software versions for notebook server images and Python packages automatically installed with each image. When we update the supported versions, we need to ensure they don't break any existing user notebooks. Users would be frustrated if they restart their server and the version updates caused something to break in an existing notebook.
The scope for this story is to investigate how we will update Python package versions without automatically potentially breaking existing notebooks.
Questions:
- do we make this an opt in model?
- If users can opt in, how do we eventually ensure package versions are updated?
This story is intended to cover updates to all packages, software & libraries included in images. That includes Python, TensorFlow, PyTorch, Cuda, and packages such as Pandas, Numpy, etc.
Adding additional notes fro Sherard on thoughts of investigating how to handle:
Have we done any research to see how competitors handle this? Maybe we should chat with some of the users of Domino to see what happens on their end.
One thing we cannot do is break their notebooks. Maybe we force the notebook into a read-only mode with a way for them to change any broken APIs, but it can't render the notebook non-functional.
You may want to collect ideas on how to handle this from various people in and outside of the team (Sophie Watson, Will Eaton, etc). If you need help gathering up some domain experts other than our engineers, I can reach out. Once we have some 1) primary research from competitive analysis and 2) feedback from domain experts, we can then put together a more formulated educated decision. What do you think?