OpenStack Upgrades
As a part of upgrading/updating our website this video 
What are your pain points for OpenStack upgrades? intrigued me and made me wonder how things have changed. I decided to chat about yesterday versus tomorrow with OpenStack experts Kevin Jackson who is Director of Product Management and co-authored “OpenStack: Building a Cloud Environment”
He said that the video is still valid.
He told me that every 6 months, the OpenStack Community used to bring out a new release of OpenStack, which spelled the end of support for older releases. This rapid release of new OpenStack versions made a lot of sense in those days when OpenStack was young, and new features were necessary to mature it, but as more and more people deployed it as a business critical platform, especially in telecommunication vertical Trilio for Telecommunication Providers it met with resistance over the years given that installations of OpenStack grew to run hundreds, if not thousands [OpenStack User Survey Analytics and Data ], of instances.
This made it so the decision to upgrade became quite a daunting task due to the complexity of the upgrade, and the risk of downtime.
Thankfully, after exhausting the alphabet of releases, the community listened and the OpenStack Community have what is known as SLURP (Skip-Level-Upgrade-Release-Process) releases (
Red Hat OpenStack Platform ] operate on Red Hat’s own support cadence and releases.
However, when the time comes – an upgrade is still required to get support, bug fixes, new features, and security patches.
Clearly OpenStack is a much broader, deeper, and therefore better platform, but the upgrade/migration issue persists and if anything, it is more complicated.
The video on our website What are your pain points for OpenStack upgrades? from OpenStack experts, is still accurate . In it the discussion is about the two ways of doing OpenStack upgrades: the in-place and the parallel upgrade, the pros, and cons of each, and how Trilio can help.
To augment the video, this blog which is based on conversations with our consultants , like Nitesh, and solution architects like Rodolfo have had with customers will hopefully help you plan and upgrade better. I have also taken the liberty of pointing to specific places in the video which should be helpful . Also, you can skip the blog and just look at the video.
Below is what I learned thanks to Kevin, Nitesh, and Rodolfo:
Complexity of the Deployment: OpenStack is a complex system with many components, services, and dependencies. No matter how much planning you do, the upgrade is susceptible to errors. For example, OpenStack has many interdependent components, and upgrading one component may require upgrading others as well. Managing these dependencies and ensuring that all components are compatible can be a significant challenge. Or when you must update the database schema, which will make data migration a complex task, ensuring a smooth transition of data from the old schema to the new one without data loss or corruption is often a daunting task.
Downtime and Service Disruption: Performing an upgrade usually requires some downtime for the OpenStack services. Minimizing this downtime and ensuring that critical services remain available during the upgrade process is business critical. Especially that OpenStack deployments often include third-party plugins and extensions. Ensuring that these plugins are compatible with the updated version of OpenStack can be challenging, especially if the plugins are not actively maintained.
Testing and Validation: Thorough testing is essential before and after an upgrade for any applications so one can identify and address any issues. However, testing a complex system like OpenStack can be time-consuming and may not cover all scenarios, leading to unexpected problems in a production environment.
Lack of Standardized Upgrade Paths and Documentation: OpenStack supports rolling upgrades, but the process often is not straightforward, and there really is not a one-size-fits-all solution. The lack of standardized upgrade paths for all deployment scenarios makes the process extremely challenging.
Resources needs and Custom Configurations: It is rare that an OpenStack deployment does not include a custom configuration to address specific use cases . Upgrading always requires revisiting and adjusting these customizations to ensure they remain effective with the updated version. On top of which the upgrade process is often resource-intensive in terms of time, personnel, and hardware. You must allocate sufficient resources and plan for potential delays to minimize the impact on operations.
Options for upgrades: There are two vastly different strategies you can use for OpenStack upgrades . An in-place upgrade is fastest, requires no additional hardware, but the downtime is unpredictable . For a more informative and detailed overview please look at the video With Trilio, in place at minute fourteen.
The other option is lift and shift upgrades, where you migrate in stages, manage downtime, but you need additional hardware, so it costs more. For a discussion about this option, please look at minute fifteen,
There is a good summary at minute nineteen , and QA at 20:30 minutes into the video.
Yesterday everything was manual, resource intensive and error prone, today some organizations use technology to simplify the upgrade process. We envision that in tomorrow’s world, to address these challenges, it is crucial for organizations to stop using traditional methods and use technology enabled upgrades. Technology enabled upgrades are much more predictable, require less resources and are much less error prone. They also include rollback in case issues arise during the upgrade process. And they make a daunting task much more manageable and help you navigate the complexities of OpenStack upgrades.
