In this post, we will explore the practical aspects of Open Data Hub (ODH), an open source project reshaping the landscape of AI and Machine Learning (ML) workloads on the OpenShift Container Platform. At the core of this project, lies a collection of pre-built, industry-optimized notebook images within the Open Data Hub, seamlessly integrated with the ODH Notebook Controller. These notebooks, conveniently bundled and ready for immediate use, cater to data science professionals and enthusiasts alike. As a member of the Open Data Hub community, I aspire to embark you on an exploration to cultivate a comprehensive understanding of its life cycle.
Navigating Image Updates in Customer Notebooks: A Practical Approach
As we continuously evolve and improve our projects, a common question arises: What happens when we update an image, such as fixing a vulnerability or updating a Python version, especially in the context of users notebooks? This concern was the crux of a recent discussion I had, and I believe the insights from this conversation are valuable for our community.
Understanding Image Updates and Customer Experience
In our product line, when an image is updated, the existing version remains active until the user decides to upgrade. During a release life cycle (the time during which it is supported), the only thing that can change is the patch version, to allow for security updates and fixes while maintaining compatibility. This approach ensures that ongoing work is not disrupted unexpectedly. We follow a structured release and support cycle, offering support for current images for one year with bi-annual releases. For example, in a given year, both ‘Version A’ and ‘Version B’ would be supported, and upon the release of a new version in the subsequent year, the older ‘Version A’ would phase out of support. However, it’s important to note that upgrading to the latest version is at the discretion of our customers.
As our notebooks undergo continuous evolution and enhancement to address vulnerability fixes, bugs, and updates, we’ve implemented a structured release schedule for new updates and improvements. Typically, these updates adhere to a 3-weekly cadence, ensuring a consistent flow of enhancements. To keep our community well-informed, we maintain a dedicated release page on our Git repository. This page, accessible at https://github.com/opendatahub-io/notebooks/releases, serves as a central hub where users can find detailed information about the latest changes, including fixes for vulnerabilities and updates to Python versions. This approach ensures that our community stays informed and can seamlessly integrate the latest improvements into their workflows.
Flexibility and Control in Upgrading
One critical aspect we’ve integrated into our system is the flexibility for customers to remain on an older version without support if they choose to. This flexibility addresses concerns about forced upgrades and potential disruptions to critical workflows. When a user decides to upgrade, our user interface simplifies the process by allowing them to select their preferred version, whether it’s the latest release or an intermediate version.
The below image serves as an example of the various versions available. While we recommend the use of the latest version by default, users have the option to revert to older versions if desired.
The registry where the notebooks are stored is on Quay.io. If a user wants to retrieve notebooks for a specific release, he ‘ll need to filter the catalog using the 5-digit Git hash provided on the release Git page. Which makes it possible to use old images that are not listed in the Version Selection dropdown.
Rollback Mechanism for Safety
A common worry with upgrades is the risk of new versions affecting existing work. To mitigate this, we’ve provided a straightforward rollback mechanism. If a customer tries a new version and encounters issues, they can easily revert to an older version by recreating it with the desired version. This rollback option ensures that our users can experiment with newer versions without the fear of permanently breaking their work.
Best Practices
In my personal experience, like what I encountered during the Innovation Day, the ability to switch between versions proved to be invaluable. It highlights the importance of flexibility and control in managing updates. Our goal is to ensure that the users can seamlessly move their code through different image versions, maintaining their productivity and stability.
Conclusion
In conclusion, our approach to image updates in customer notebooks is designed to be user-centric, providing stability, flexibility, and control. By understanding and implementing these practices, we can ensure a smooth and efficient workflow for our customers, even as we continually improve and update our offerings.
Useful links
- Try OpenShift AI in a Sandbox: https://developers.redhat.com/products/red-hat-openshift-ai/getting-started
- Open Data Hub: https://opendatahub.io/
- Notebooks: https://github.com/opendatahub-io/notebooks
