Mark your calendars for October 17–19, 2025, when the OpenInfra community converges on École Polytechnique in Paris‑Saclay for the much‑anticipated OpenInfra Summit Europe. The schedule was just published today, and among the open infrastructure focused tracks, OpenStack remains central—featuring in core presentations, Forum discussions, workshops, and keynotes.
The OpenInfra Summit schedule is curated by experts from the global community who volunteer their time to make the content as engaging and representative as possible. Some highlights among the 80+ OpenStack sessions include:
Keynote attendees will see a multi-participant, simultaneous demo highlighting the variety of paths organizations can take to migrate workloads from VMware to OpenStack. Participants currently include Canonical, Rackspace and ZConverter.
Attending OpenStack sessions at OpenInfra Summit Europe offers a chance to:
Gain early access to Flamingo roadmap discussions
Learn from migration success stories and production use-cases
Network with contributors, team leads, and users worldwide
Influence the future direction of OpenStack through Forum collaboration (The Forum CFP is open until 8 July!)
If you’re passionate about hybrid clouds, open infrastructure, and cutting-edge OpenStack innovation, these sessions are unmissable. Check out the full agenda—and don’t miss your chance to engage, learn, and contribute at the OpenInfra Summit Europe this October!
In the wake of Broadcom’s 2023 acquisition of VMware, the enterprise IT world found itself at a crossroads. Rapid, unexpected changes to VMware’s licensing model sent shockwaves through thousands of organizations, forcing a stark choice: stay and absorb dramatic cost increases—or seek out an alternative platform capable of handling mission-critical workloads.
Enter OpenStack
For many organizations, OpenStack was that cloud they looked into 10 years ago and decided that it wasn’t the right platform for them at the time. Since then, thanks to thousands of contributors and hundreds of organizations, OpenStack has matured significantly into a stable platform trusted to handle any workload. It has simplified and addressed feedback from users. It has been adopted and evolved by thousands of developers at hundreds of organizations all around the globe. OpenStack has evolved to support complex, large-scale infrastructure with power and flexibility.
With a second look, organizations around the world are discovering just how much the OpenStack marketplace has grown in the last decade. There have been 21 releases since 2015 and with each one there have been numerous upgrades and advancements. These organizations have a lot of questions though; namely, how does a migration from VMware to OpenStack work?
Available Today: A Comprehensive VMware-to-OpenStack Migration Guide
Last year, the OpenInfra Member community collaborated to create the VMware Migration Whitepaper to start a public dialogue positioning OpenStack as an option in this quest for a virtualization alternative. It helped educate this market on the why of the situation – why OpenStack could be a strategic, cost saving alternative. As a result, questions are now focused on the how.
Today, I am proud to introduce the VMware Migration Guide, which answers these questions. The idea behind the guide is to build on the foundation that last year’s white paper began. The Guide’s aim is to prime the organizations for making the move to OpenStack by helping with the planning stages, the candid assessment of the existing stack, and setting up a mindset for modernizing infrastructure and the operating model.
The Guide was created by a group of OpenInfra community members with experience and knowledge in this space and includes:
Case Studies of real world workload migration
Reference architectures to show how an OpenStack cloud offering might be laid out and how that can serve the workload that is currently on VMware
Considerations, comparisons and the clear benefits of moving to OpenStack to avoid vendor lock-in and capitalize on all that comes with leveraging an open source solution
How OpenStack Introduces Benefits of Open Source to a Previously Locked In Crowd
As organizations consider the move from a proprietary solution like VMware to an open source based product, the benefits are not limited to a reduction in licensing costs. The most impactful benefit is actually the dissolution of vendor lock-in; you are no longer bound to the decisions or product roadmap of a single vendor. The OpenStack Marketplace proves there is an entire ecosystem for you to explore and interoperability you can leverage until you find the right partner.
Beyond the Marketplace, OpenStack is backed by a global community openly developing code that is better tested and more robust. Now is the time for your organization to take another look at OpenStack. Learn more about the benefits and challenges of VMware to OpenStack Migration and join this global movement.
Oria Weng is a third-year honors student studying computer science at Oregon State University, working at the Oregon State University Open Source Lab (OSUOSL).
What Open Infrastructure project are you working with, and what made you interested in that project, as opposed to some of the other options? What was the hardest part about getting started?
I believe it was Kendall Nelson who connected the OSUOSL with the internship program; I joined work on OpenStack Client (python-openstackclient), the command line client, after Antonia Gaete, another past intern, had started working on it. It made sense logistically for us to work under the same mentors (Stephen Finucane and Artem Goncharov) and on the same project, but I did like specifically working on identity because things like users, projects, etc. were things I had to use pretty often in my own usage of OpenStack. Plus, it was a good opportunity to learn more about security concepts like authorization and authentication. Later, Artem introduced us to his API schema work on Keystone, the identity service, and invited us to help with that. I’ve really enjoyed working with APIs in the past, so this sounded like a fun opportunity. I especially liked the idea that enforcing a strict API schema could (potentially) make it easier to find inconsistencies and bugs, as well as improve the understandability and documentation of Keystone.
What was the hardest part about getting started?
This was my first time working on a big open-source project at this scale, so the hardest part for me was understanding how the codebase fit together and figuring out which of the moving parts I should change to accomplish something. What helped me the most was to look at examples of other changes – for example, I studied Antonia’s changes as I was starting out, since she had started at OpenStack earlier than me and was doing similar work. It also helped a lot to have mentors who knew the codebase inside and out and were willing to answer any questions that came up.
What could have made the getting-started process easier?
I think the docs were pretty overwhelming for me as I was starting out – each project has different categories of references and guides as well as multiple project versions; there are also both contributor guides for individual projects and ones for OpenStack overall. Fortunately, I had help from mentors like Kendall, Stephen, and Artem to figure things out, but I think a short guide for total beginners on how to navigate the projects and their docs would be helpful. 🙂
How have you contributed to the community?
For OpenStack, I’ve primarily been helping to migrate OpenStack Client commands to use the OpenStack SDK (to move away from keystoneclient) as well as adding API schema validators to Keystone. In terms of the open source community in general, this is my third year working at the OSUOSL, where we provide hosting and other services to over 160 open source projects. I think that’s pretty cool!
What’s the biggest benefit from your involvement? (hard or soft skills, connections, etc)
One of the biggest benefits for me was just getting used to development on a big open source project. Before going in, I didn’t really have a good idea of how open source development really worked; I learned a lot about best practices and how to communicate.
What advice do you have for students who want to get started with open source?
Don’t be afraid to ask questions! As I was starting out, I probably looked even sillier pretending I knew what was going on when I didn’t, than I would have if I’d just asked an “obvious” question.
As the academic year wraps up, seniors at Dickinson College have completed their capstone course, where they learned a lot during the past year, including new concepts, how OpenInfra works, working with the Swift core team, and we getting to attend the Project Teams Gathering (PTG).
This year, James Nguyễn, Nathan Nguyễn, and Boosung Kim were among the fortunate few who had the chance to work with OpenStack. In a recent interview with one of the students, Boosung Kim shared insights into how he became acquainted with OpenStack, what surprised him the most, the challenges he encountered, and the advice he’d offer to future students.
Boosung is a senior double majoring in Computer Science and Math, graduating this year. He is currently wrapping up his final semester while contributing to OpenStack Swift. Outside of school, he enjoys attending hackathons and swimming!
What Open Infrastructure project are you working with and what made you interested in that project, as opposed to some of the other options?
I’m working with OpenStack Swift. I was drawn to it because of my interest in large-scale systems and backend infrastructure. Swift stood out from other projects due to its clean design, active community, and relevance to the kind of distributed systems I want to build professionally.
How did you get started? What was the hardest part?
I got started by joining Dickinson College’s seminar focused on open source development, where I chose Swift for a technical deep dive. I began by exploring the codebase, setting up a dev environment, and meeting the Swift team during the 2024 PTG.
The hardest part was grasping new concepts like race conditions, erasure coding, and heartbeats. These were outside the scope of my usual coursework, so it took extra time to understand how they fit into a distributed system like Swift.
What could have made the getting started process easier?
Clearer beginner-focused documentation on core concepts like consistency, replication, and concurrency in Swift would have helped. But the dev team was willing to hop on a call to explain these concepts in-depth, so everything worked out regardless.
How have you contributed to the community?
I’ve contributed code patches to the Swift project, participated in review discussions, and gave a tech talk at my college to introduce others to OpenStack and Swift. I hope that my contributions can be of help to Swift users and that more students from my college will work with OpenStack.
What’s the biggest benefit from your involvement?
The biggest benefit has been learning how real-world distributed systems are built and maintained. I also gained experience navigating large codebases, writing production-level code, and communicating effectively in an open-source community.
What advice do you have for students who want to get started with open source?
Don’t try to perfect your patches before submitting for review like I did. Aim for quick, purposeful iterations so that you can get reviews fast and ship fast.
The OpenInfra Project Team Gathering took place April 7 to 11, earlier this month. A variety of OpenStack teams, covering the basic OpenStack services, pop up working groups, among other more horizontal view teams met to have technical discussions throughout the week. Discussions ranged from ongoing feature work, to reviewing feedback on the most recent Epoxy release, to planning for the future and everything in between.
Some highlights were the revival of interest in Watcher which has been rejuvenated by a number of organizations looking to migrate from VMware and OpenStack being well poised as an alternative. The technical committee held a community leaders forum to bubble up issues affecting teams and reignite awareness about the Vulnerability Management Team and ongoing community goals. Also this PTG, OpenStack Operators and community members gathered to discuss how to better engage with people in operations roles and re-frame the way they collaborate as a group and participate in the larger community.
For more information about discussions that went on at the PTG, you can find find a list of the team summaries that have been published below.
Thank you to everyone that participated in this PTG! If there are any summaries missing from this list, please reach out to [email protected] to get them added here.
The OpenStack community’s latest release, 2025.1 Epoxy, marks an important milestone in the project’s evolution. With the release of OpenStack Epoxy, the project continues to improve its capabilities, positioning itself as a more viable alternative to proprietary solutions like VMware. Packed with a range of new features, security enhancements, and hardware enablement improvements, Epoxy is poised to support more complex and demanding workloads while offering more efficient management tools for cloud administrators.
OpenStack’s adoption is on the rise, and this release demonstrates the community’s commitment to its growth and evolution in the face of industry trends and opportunities. The 31st release of OpenStack is the result of contributions from around 450 developers from leading organizations such as BBC R&D, Blizzard Entertainment, Canonical, Ericsson, Mirantis, NVIDIA, and others. Together, they’ve delivered more than 7,600 changes, including new features and significant maintenance updates. This release also comes as the OpenStack community celebrates its 15th anniversary, a testament to its continued relevance and importance in the cloud computing world.
Strengthening OpenStack’s Position as a VMware Alternative
Broadcom’s acquisition of VMware and subsequent licensing changes have incentivized organizations around the world to re-evaluate their virtualization strategy. OpenStack has emerged as a leading VMware alternative, and the upstream community is evolving OpenStack to address this market opportunity. One of the standout features of OpenStack Epoxy is the enhanced VMware migration capabilities, especially through the integration of Prometheus within the Watcher project. Watcher is a component of OpenStack designed to optimize resource allocation. With the addition of a Prometheus data source, OpenStack can now more effectively monitor existing VMware infrastructures, making it easier to track performance and detect bottlenecks during migration. This feature is invaluable for businesses looking to migrate from VMware to OpenStack, as it ensures a smooth transition without performance degradation.
Additionally, Epoxy introduces improved support for a range of storage solutions through the Cinder project. Cinder, OpenStack’s block storage service, now includes updates for many supported hardware drivers, such as NetApp, Pure Storage, and Hitachi. These improvements help organizations that rely on specific storage solutions to migrate their workloads to OpenStack more easily. After migration, the compatibility between OpenStack and existing storage infrastructures ensures seamless data access, reducing the risks associated with switching to a new platform.
Enhancing Security Features
Security remains a top priority in the Epoxy release. A significant upgrade comes to Manila, OpenStack’s shared file system service. In Epoxy, Manila users can now modify the access level of share access rules, switching from “read-only” to “read-write” or vice versa. This gives administrators greater control over who can modify and access shared data, improving the overall security of the cloud environment by reducing the risk of unauthorized changes.
Additionally, Manila users can now set and modify share server characteristics through share network subnet metadata. This feature allows administrators to define permissible modifications through a configuration option called driver_updatable_subnet_metadata. The result is improved network isolation and segmentation, reducing the risk of lateral movement in case of a security breach. By ensuring that different data sets are isolated on separate subnets, the security of the network is significantly enhanced.
Another noteworthy security feature comes to Octavia, OpenStack’s load balancing service. In this release, Octavia now supports custom neutron security groups for load balancer VIP (Virtual IP) ports. By associating specific security groups with VIP ports, administrators can ensure that only approved traffic types are allowed to access the load balancer, further reducing the risk of unauthorized access.
Improving Hardware Enablement
OpenStack Epoxy also brings important hardware enablement updates, particularly in support of AI and machine learning workloads. One of the key improvements is the addition of a new interface in Ironic, OpenStack’s bare-metal provisioning service. This interface allows for the deployment of bootable container images directly to a host without intermediate steps, simplifying the deployment process for operators and users alike.
Another significant update comes in Nova, OpenStack’s compute service, with improvements to PCI passthrough. PCI passthrough allows virtual machines to access physical hardware devices directly, and the Epoxy release expands support for the vfio-PCI variant drivers, including Nvidia GRID on Ubuntu 24.04. This enhancement ensures that OpenStack can more effectively support AI workloads by allowing for the direct use of GPUs and other specialized hardware in virtualized environments. Additionally, this update enables live migration of instances using these PCI devices, further improving the flexibility and scalability of OpenStack environments.
Simplifying OpenStack Upgrades
The OpenStack community continues to focus on simplifying the upgrade process for users. The Skip Level Upgrade Release Process (SLURP), introduced in 2022, allows users to upgrade to the next major release every year rather than every six months. This release cycle simplifies the process for administrators, reducing the frequency of major updates while still delivering new features and security patches. The Epoxy release (2025.1) follows the previous SLURP release (2024.1 Caracal), making it easy for organizations to upgrade directly from one release to the next without worrying about incremental updates.
