OpenStack global footprint exceeds 45 million compute cores as users tackle common obstacles

The 10th iteration of the OpenStack User Survey highlights expanding footprint of OpenStack clouds, reinforcing architecture trends and introducing new usage patterns  

Over the past 10 years, over 2,200 organizations have voluntarily contributed OpenStack usage data and architecture details, across more than 4,000 deployments as well as feedback for the upstream community to improve the software. Over the decade of measurement, several trends emerged: 

  • The OpenInfra Standard, LOKI (Linux OpenStack Kubernetes Infrastructure), is consistently measured in over 70% of reported OpenStack deployments. Specific components within OpenStack that have seen an increase in adoption over time to deliver this integration include Magnum, Ironic, Kuryr, Kolla, and OpenStack-Helm.    
  • A hybrid cloud approach is adopted by most cloud users, and this trend is supported by a growing marketplace of OpenStack public and private cloud providers. While AWS remains the most common hyperscaler integrated with OpenStack, the OpenStack-powered public cloud network now exceeds 300 data centers worldwide.  
  • Upgrades were a common pain point which prevented many organizations from running the most recent release. 

While the 2023 analysis continues to highlight these trends, new patterns are emerging that have been reported as too complex in previous years. Organizations with smaller teams have proven that a massive internal team is not required to operate an OpenStack cloud, recent releases are gaining traction highlighting community progress in improving upgrades, and the OpenStack footprint continues to grow both with new clouds coming online as well as growth among OpenStack deployments of all sizes. Additional 2023 data around OpenStack operator demographics, deployment decisions, and cloud size can be found on the OpenStack analytics dashboard

Global OpenStack Footprint Grows with New Clouds, Growth Across Deployments of All Sizes

The first recorded measure of aggregated OpenStack compute cores was 10 million in 2018. Five years later, the footprint has grown 350% to 45 million compute cores powered by OpenStack running in production. While the growth is most notable among the world’s largest deployments, the growth continues to be seen across deployments of all sizes, regardless of industry and geography. 

A significant contributor to this is LINE, the Japanese messaging app that recently merged with Yahoo! Japan to form LY, whose OpenStack deployment grew from 4 million cores last year to 6.9 million cores this year. Large scale OpenStack user Workday also added another 800,000 cores and OVH reached the 1 million core threshold for the first time and its engineers say this growth is expected to continue. 

While not all deployments are cataloged in the OpenStack User Survey, new clouds continue to be reported. This year, 12% of the clouds came online within the past nine months highlighting that even 13 years in, OpenStack continues to be adopted to set up new public and private cloud infrastructure. 

Smaller Teams Turning to OpenStack Clouds

One of the most interesting data points is around the number of deployments for organizations with 10-99 employees. Around 23% of deployments are managed by an organization this size and that’s the highest percentage this segment has had since 2015. The industry spread here is across academic / research and IT, showing that smaller organizations are having more success in getting OpenStack running in production. 

OpenStack Users Increasingly Implementing Recent Releases 

This year, 81% of OpenStack deployments run a version within the last 5 releases compared to 72% in 2022. The OpenInfra Foundation anticipates that this percentage will continue to improve with the implementation of a new release cadence this year. OpenStack 2023.1 (Antelope), released in March 2023, was the first in the Skip Level Upgrade Release Process (SLURP) cadence recently established by the Technical Committee. Every other release will be considered to be a “SLURP” release. Deployments wishing to stay on the six-month cycle will deploy every “SLURP” and “not-SLURP” release as they always have. Deployments wishing to move to a one-year upgrade cycle will synchronize on a “SLURP” release, and then skip the following “not-SLURP” release, upgrading when the subsequent “SLURP” is released. The community is hopeful that this alleviates some of the complexities within the OpenStack upgrade process.

Share your feedback 

The OpenStack User Survey is open year-round, and is hosted by the OpenInfra Foundation, who supports the OpenStack community as well as other open source projects. This survey captures the deployments and feedback cataloged between August 2022 and August 2023 and this report aggregates trends and notable statistical growth.

The OpenStack User Survey is an annual, opt-in survey for organizations running OpenStack. The analysis presented in this report represents the shared information, but the actual footprint of OpenStack powered clouds is much larger. If you are operating an OpenStack cloud or operating clouds for customers, please take the 2024 User Survey so we can understand the global footprint and pass your anonymous feedback along to the upstream development teams.

New in OpenStack Bobcat: Ironic team supports servicing nodes

Ironic now enables infrastructure operators to modify existing nodes using the “service steps” framework. Servicing allows operators to leverage steps, like you would for cleaning or customized deployments, to perform actions to modify deployed nodes in an ACTIVE state.

Previously, Ironic would not perform operations on active nodes, largely due to standing technical consensus within the Ironic project. Recent operator feedback and additional new features added to help model and support Data/Infrastructure Processing Units (DPUs/IPUs) has driven the Ironic community to re-evaluate this consensus and to adapt the capabilities in order to  add this new feature.

The main reason we envisioned for this feature was to enable infrastructure operators to perform firmware/software upgrades on these DPU/IPU devices, which are very much like embedded devices enabling a more performant and capable infrastructure environment. Much of Ironic’s work this past cycle was focused on this and similar use cases surrounding add-on Processing Units and their management which also impacts the management of the base physical machine.

Ironic operators have also long sought capabilities to make major changes to deployed nodes in a self-service and automated fashion. These operators have long wanted to perform actions such as re-configure RAID, apply firmware updates, or even re-execute benchmark operations. These actions are often necessary in the world of physical baremetal servers when performing both day to day maintenance as well as working to repair or verify that the equipment has been successfully repaired. The power of Ironic enables that operators can work to perform these actions at scale in an automated fashion, reducing the need to interact with individual server nodes to achieve the same results. This way operators are no longer forced to migrate workloads for relatively minor system modifications.

This added functionality represents a major step forward in terms of capabilities, and also the evolution of capabilities driven by human feedback in our Open Source communities. The project recognizes with any new and complex feature there may be additional room for improvement, or potential edge cases which we did not anticipate, and as such we do expect to continue to work in the area of these features in the coming development cycle (2024.1 “Caracal”) to harden as well further extend these capabilities with an eye on enabling simplified paths to manage complex nested structures within a bare metal node, the foundation of the modern data center. This space is made particularly challenging due to the increased adoption of Add-On Processing Units, but the Ironic project is up to the challenge.

If you’re an infrastructure operator, and interested in joining the discussion during the upcoming PTG, you’re welcome to join us in discussion during the upcoming PTG. Make sure you register for free ahead of time and find out about the topics.

You can learn about  the new Servicing feature, individual steps, and the cleaning framework this feature is built upon.

Learn more about OpenStack Bobcat, the 28th release of OpenStack, that was released on October 4, 2023.

Tags:

New in OpenStack Bobcat: Manila team introduces resource lock framework

My name is Goutham Pacha Ravi and I am a core contributor for the OpenStack Manila project. Below is a feature request that was reported by an operator who would like to remain anonymous. Luckily, the operator engaged with the upstream OpenStack community and this feature has been delivered in OpenStack 2023.2, nicknamed the Bobcat release.

An operator reported to the OpenStack Manila team that a user deleted a share from Manila without realizing that the action would be irrevocable. The user later realized that an application was actively writing data into the share, and it crashed when the share was deleted. Unlike block storage volumes, shared file systems do not track connected clients, so there was no pre-condition that prevented the share to be deleted. The user did not perform a “soft-deletion” that would have relegated the share to a recycle bin for a specified duration, they had requested a permanent deletion. The user did not use the OpenStack Dashboard GUI (Horizon) which would have presented a confirmation dialog for the deletion. The user hadn’t taken a snapshot of the share from which the data could have been restored. Unintentional actions like this could jeopardize business continuity. So, Manila’s resource locks were designed to avoid such situations. They allow building a safety hatch on top of the limitation in traditional shared file systems and track in-use shares. Users may create any number of locks for any number of reasons on a given share, thereby preventing actions that may be detrimental to their use case.

A resource lock can currently protect shares and their access control rules from deletion. Since a shared file system is built for concurrent access from multiple OpenStack users within a project, multiple locks can be created. While creating a lock, the user provides the action they would like to prevent and a reason for the lock. The resource lock is then treated as a precondition that the API checks for when completing an action. If there are any locks that prevent an action, the action is aborted and the user requesting the action is provided an appropriate feedback. 

Resource locks can also be applied to hide sensitive fields within access control lists of shared file systems. Normally,  access control lists are available to all project users. However, there may be situations where a user wants to prevent other project users from gathering the access secret keys or a client identifier, such as the IP address of the hosts that are provided access. By placing a visibility lock during the access rule creation, the user can ensure that this data stays hidden to other users in their project. You can access the resource lock specifications here and here.

At the OpenInfra Summit Project Teams Gathering (PTG), we received a lot of interest for an upcoming feature in OpenStack Nova, VirtIOFS attachments. Through VirtIOFS, shared file systems from OpenStack Manila can be connected to virtual machine instances in a secure, hypervisor-mediated manner akin to block storage volumes. Nova would need to place a deletion lock on the share while it is attached to a virtual machine. It was hence important for resource locks to be introduced in Manila. VirtIOFS is a much anticipated feature in particular for public cloud operators who helped us prioritize its delivery in the upcoming cycle. Independently, the Manila team plans to continue extending the resource locks framework to other API resources and actions in the upcoming releases.

“The VirtIOFS feature is something that we at Cleura have been looking forward to, as this will make the architecture much better for us as an operator of public clouds. It also makes the user experience and resource efficiency much better for the end users, creating the same look and feel as working with block storage volumes. The resource lock feature is crucial here as well to get that great user experience. With these features in place we feel confident in bringing Manila into production and make the much requested functionality of shared file systems as a service available to our customers. We are really greatful for the good collaboration with the community, and the Manila team in particular, it really shows how important the collaboration between operators and developers is, and how we together can do great things with that collaboration.” – Tobias Rydberg, head of design and architecture at Cleura

Thank you to the contributors who joined me in delivering this feature for the OpenStack Bobcat release, Rene Ribaud, Software Engineer at Red Hat and Carlos Eduardo da Silva, Software Engineer at Red Hat.

The discussion will continue at the upcoming virtual PTG (October 23-27) where operators and developers will discuss Manila features and bug requests planned for the OpenStack 2024.1, Caracal release.

Learn more about OpenStack Bobcat, the 28th release of OpenStack, that was released on October 4, 2023.

 

Tags:

New in OpenStack Bobcat: Horizon team introduces time-based one-time password (TOTP) authentication support

Horizon added time-based one-time password (TOTP) authentication support, leveraging the already existing two factor authentication from Keystone. Now, if a user activates TOTP on Keystone, it gets activated on Horizon too. 

This specific feature request was a demand from Infomaniak’s public cloud customers. They wanted the feature to have TOTP in Horizon, as they were feeling rightly that this would improve security. If a user on an OpenStack cloud gets their password compromised (stolen, laptop hacked, etc), then the TOTP still requires a second device. The TOTP authentication token is usually stored on a phone running Android or IOS (but there is also “numberstation” for example, that can run on any Debian-based OS, including the Mobian platform, so it really runs on any phone).

As an OpenStack operator, it is Infomaniak’s policy to always send patches upstream, and never put in production patches that haven’t been merged. Once a patch is merged, it can usually be backported in the unofficial Debian package backports is maintained on http://osbpo.debian.net. This way, there is always a working upgrade path, which is super important.

This feature is a significant contribution to OpenStack Horizon, because if there were a problem on OpenStack, and TOTP was enabled only in Keystone, the user would not be able to connect to Horizon. This would have removed an operator’s access to the web interface to manage the rest of its OpenStack services. 

Benjamin Lasseye, site reliability engineer at Infomaniak, started by trying out different mock-ups on April 24, 2023. Once he was happy with the user experience, he went ahead with the feature.The first patchset was sent June 6, and the patch was merged on August 29. It took a surprising long time, because from early June to end of July, the Horizon CI was broken, so there was no way to check if our patch was breaking anything. Thomas wrote to the mailing list to ask what was going on, and the Horizon team was able to reply nicely with a coherent explanation: there was a mixture of JQuery related dependency hell that they had to tackle. In this type of case, one just need to be patient.

Then it took up to 29 patch iterations to get things right. Benjamin was very patient and addressed all the suggestions from the Horizon core team to get to this result.

All this was only possible because there is a proven way to get patches merged in upstream OpenStack that was carefully followed. One must make sure to include in the patch: 

  • a correct documentation
  • a release notes 
  • some meaningful unit or functional tests

In terms of feature completion, Benjamin has made it easy to activate the OTP feature, which is OFF by default to allow smoother upgrades. After more feedback, it could be implemented in Horizon’s default configuration. There is also still room for more contribution. There could be a feature in Horizon so an admin could activate TOTP for a user using Horizon. Even though anyone could contribute the feature, Infomaniak is not planning to do it, as the automated task is done in their own web interface, using the Keystone API (via the openstacksdk). 

To be enable TOTP,  here is some guidance and documentation:

We welcome the OpenStack operator and developer community to continue the work we have started here to continue to prioritize security for all OpenStack Horizon users!  

Thank you to the OpenStack contributors who helped build, review, and merge this feature for OpenStack 2023.2, Bobcat:

  • Vishal Manchanda, technical lead from NEC Corporation, India, was very helpful, and wrote many comments in the patch review.
  • Radomir Dopieralskim, software engineer from Red Hat in Poland, also helped with reviewing the patch.
  • Benjamin Lasseye, SRE at Infomaniak, is the main author of the patch.
  • Thomas Goirand, senior OpenStack administrator at Infomaniak and Debian package maintainer of OpenStack since 2011, advised and helped Bejamin getting the patch in a good enough shape so it could be merged.

About Infomaniak: 
Infomaniak has been using OpenStack in production since 2014, first providing a VM service, which they still do. Infomaniak operates now a moderately large public cloud cluster (10k physical core, with more than 1PB NVMe Ceph storage, powering about 4k VMs). Infomaniak also offers the best pricing available on the market, running on recent hardware (AMD Epyc and Gen 4 NVMe). Everything is setup and maintained using free software, including a cluster management tool, a billing add-on to Ceilometer, or some Designate tools. All of this, is uploaded to Debian (as Thomas Goirand has been maintaining OpenStack in Debian since 2011). This public cloud service has been running for two years already, and Infomaniak is currently working toward setting-up a 2nd region in their new data center that is about to open for production (hopefully, that done for early 2024), using even more up-to-date hardware (AMD EPYC Genoa, PCI 5, DDR5, etc.).

Learn more about OpenStack Bobcat, the 28th release of OpenStack, that was released on October 4, 2023.

Tags:

Lifetime OpenStack Contributor Metrics Now Available in Bitergia Dashboard

Contributing to OpenStack and joining the community is one of my proudest accomplishments, hands down. In fact, I actually have a skirt printed with lines of code showing the state of OpenStack (projects.yaml) from the day my first patch landed in Cinder. 

But it’s definitely not just me that has made OpenStack into one of the top five most active open source projects in the world. Thousands of contributors from around the world have delivered changes, bug fixes, and documentation. The data behind these contributors has been something we announce twice a year, with each new software release, but it hasn’t been available to the general public in a clear and easy way to explore. Until now. 

During the OpenInfra Summit Vancouver keynotes this morning, I had the pleasure of announcing the availability of an OpenStack dashboard that collects and analyzes the data behind the OpenStack repositories. This dashboard is made available by Bitergia, the official metrics partner of the OpenInfra Foundation. 

Here are some trends and data points that the dashboard provides: 

  • The evolution of contribution to the different OpenStack projects over time
  • The distribution of repositories across OpenStack components 

The part that I am most excited about is that the OpenStack contribution data can also be visually connected to data from adjacent open source communities, like Kubernetes. This illustrates the power of cross-community collaboration to ensure interoperability between the two projects – something that thousands of organizations rely on. 


If you want to become part of this intertwined network, the OpenStack community is always welcoming new contributors! Reach out to the First Contact SIG or check out the Upstream Investment Opportunities list for more information! 

Calling all OpenStack Operators! The PTG starts Monday, and the community needs your input!

I’m an OpenStack Operator going to the PTG, where should I go? 

PTGs aren’t just for OpenInfra developers! The discussions need perspectives from a broader group to make the event successful. This includes operators who are running OpenInfra projects in production (Public and Private Cloud, Research, etc), plan to run a project in the future, or simply projects that you have feedback for.  Even if you are running an older release of OpenStack, your feedback and questions and opinions are still incredibly valuable!

The schedule is mostly setup in the PTGbot and you are encouraged to attend any that fit with your schedule! Agendas can be found in the project etherpads here. Aside from the OpenStack Operators session taking place on Thursday – you are a team as well afterall! – there are a few sessions that would be good to make sure are on your list of discussions to attend.

Registration is free.

Monday:

Tuesday: 

Wednesday:

Thursday:

Friday:

There are a lot of opportunities to make an impact on the software and help the community next week; please get involved!

Virtuozzo joins the OpenStack Marketplace, and Sharktech does too. Shouldn’t you?

We’re excited to announce that Virtuozzo is now part of the OpenStack Marketplace – and even better, our US cloud partner Sharktech has joined too.

The OpenStack Marketplace has a simple goal: to make it easy to find cloud services and technologies that help you leverage the awesome open-source OpenStack framework. It’s a natural home for Virtuozzo Hybrid Infrastructure, our production-ready OpenStack cloud platform.

By making OpenStack easy to deploy, manage and update – and easy to monetize – Virtuozzo enables any Cloud Service Provider, MSP or Telco to offer a much more affordable and compelling alternative to hyperscale clouds like AWS and Azure, without the time and cost of developing their own solution.

You can now find Virtuozzo in the OpenStack Marketplace Distro, Public Cloud and Hosted Private Cloud categories – check them out!

“There’s a shift underway in the market as organizations realize that managed services for open-source projects like OpenStack have matured to become full-fledged competitors to hyperscale cloud providers. This shift is both healthy and necessary, as organizations work to claw back control over their data and where compute takes place. The rapidly growing, global footprint of OpenStack managed services is contributing to this shift, and it’s exciting to see collaboration among players like Virtuozzo and Sharktech delivering these services at scale,” said Jimmy McArthur, Senior Manager of Community and Business Development at OpenInfra Foundation.

OpenStack at the Heart of Alternative Cloud

Speaking about the news, Virtuozzo CEO Alex Fine said: “Wherever we turn and whomever we speak to – cloud users, cloud providers, analysts or partners – the message is clear: the world needs an alternative to the super-complex and expensive hyperscale clouds.”

“Virtuozzo is leading the charge to make cloud easy, accessible and affordable for all. That is what we call the alternative cloud, and OpenStack technologies are at its heart. We’re excited to be part of the OpenStack Marketplace, along with more and more of our partners – the companies bringing alternative cloud services to businesses across the world.”

Building the future of cloud with OpenStack technologies is part of our long-term commitment and passion for open-source. For more than 20 years, the Virtuozzo engineering team has been actively contributing to OpenStack, Linux and the Linux kernel – including KVM, QEMU and LibVirt, CRIU and P.Haul – and of course OpenVZ, and VzLinux, our own free distro.

Sharktech Joins, Too

The latest Virtuozzo partner to join the marketplace is Sharktech. Founded in 2003, Sharktech has grown from its headquarters in Las Vegas to offer a range of hosting services from datacenters in Los Angeles, Denver, Chicago and Amsterdam.

In 2021, Sharktech launched a new range of cloud services based on Virtuozzo Hybrid Infrastructure. Sharktech is now an important part of the Virtuozzo cloud ecosystem, not just for SME and enterprise users, but for other service providers looking to build their own cloud services business.

“OpenStack always had the potential to become the de facto cloud platform, but for hosting providers like us, it was always kind of daunting. That isn’t because we don’t have the skills to build our own OpenStack cloud – it’s just the time and cost of building it ourselves,” said Sharktech CEO, Tim Timrawi.

“Virtuozzo has streamlined OpenStack, removed the complexity and packaged it in a way that makes sense for service providers. As a result, we can bring high quality, ultra-robust and very cost-effective services to market – and of course, we’re excited that Sharktech cloud is now easy to find through the OpenStack Marketplace.”  

More Info

Virtuozzo is the easiest way for service providers to create their own profitable, successful cloud services business.

Learn more about Virtuozzo Hybrid Infrastructure, and don’t forget to check out Sharktech.net… …and of course, if you already offer cloud based on Virtuozzo Hybrid Infrastructure, get your brand and services added to the OpenStack Marketplace!

What Operators Can Expect to Discuss with the OpenStack Manila Team at the PTG

If you’re an OpenStack operator, you should check out my previous blog post about why you should attend the upcoming Project Teams Gathering (PTG). In an effort to help OpenStack operators get the most out of a PTG, we surveyed some project team leads (PTLs)  about the operator engagement they would most like to see. First up, we have Nova!

Special thanks to the Manila team, lead by PTL Goutham Pacha Ravi for taking time to put together these responses.

What do you want to hear from operators about at the PTG?

In the Shared File Systems service (manila) project, for the past three virtual PTGs we have invited one or two operators to share specific concerns with us. The discussions that followed have spawned several bugs and blueprints. We’ve discussed operational best practices, sporadic problems that arise at scale, storage for application containers, continuous integration testing, interoperability and missing features.

For this PTG, we would like to do the same – the strategy of keeping it to a few burning issues has certainly been very helpful. Our topics aren’t set in stone yet, but for starters, we’d like to get operator feedback on deploying and managing Manila with CephFS. Alongside, we want to know the strategies used by operators to maintain high availability of the control plane; and finally, we want to get feedback on several parallel community-wide efforts:

  • Secure RBAC and “system” personas
  • Federal Information Processing Standards (FIPS)
  • Adoption of the OpenStackClient

What topics are already on your agenda?

We’ve started collecting them here: https://etherpad.opendev.org/p/columbus-ptg-manila-planning

What are your goals for the October 2022 PTG?

Streamline and prioritize code contributor and reviewer efforts for the Antelope cycle, highlight technical debt and get help.

We look forward to seeing EVERYONE at the PTG in October! Registration is currently open and free to everyone who would like to attend. If you haven’t signed your team up yet, do it by August 26!

What Operators Can Expect to Discuss with the OpenStack Nova Team at the PTG

If you’re an OpenStack operator, you should check out my previous blog post about why you should attend the upcoming Project Teams Gathering (PTG). In an effort to help OpenStack operators get the most out of a PTG, we surveyed some project team leads (PTLs)  about the operator engagement they would most like to see. First up, we have Nova!

Special thanks to the Nova team for taking time to put together these responses.

After talking things over with his team, Sylvain Bauza, the Nova PTL, sent us some summaries of feedback they collected in this etherpad:  https://etherpad.opendev.org/p/nova-ptg-columbus-ops-presence.

What do you want to hear from operators about at the PTG?

In general, we expect some feedback from the operators about their usecases and how they use some Nova features when we discuss about some new design enhancements in the PTG room.But this time, as we had a meet-and-greet session in Berlin where operators also provided their pain points, it would be nice if we could also discuss about those issues and what we could do for fixing them.

What topics are already on your agenda?

In general, we only have an agenda in the last week(s?) before the PTG but we already have some points we know we would like to discuss : 

  • Ironic has an issue with rebalancing nodes so I’d love to discuss with both the Ironic contributors but also the operators to understand their problems and how we could fix this. 
  • Given of the new RBAC policies, we would need to continue discussing how to modify our APIs for them. Having for example public cloud operators around would be loved as they could explain us which kind of values they would like to see as default. 
  • Because of the new tick-tock release model, we need to think about both the Antelope release and the BB and CC releases to see how we organize upgrades. 
  • We also want to discuss about sustainability in Nova and how to support Scaphandre. I guess operators would like to hear about what we could work on Antelope and what they would prefer to see first. 

What are your goals for the October 2022 PTG?

Basically, planning the Antelope release from a design perspective and discussing about next cycles (at least for BB and CC releases), like we do at every PTG, but if were having operators, we could also make sure we would have a specific Nova operators-welcome day (eg. on Tuesday) where the team would discuss about features and pain points while refraining ourselves to go into technical deepdive discussions with whiteboards etc.

This is just ONE team, there are already about a dozen teams signed up to participate, and there’s still more time for teams to signup so we expect there will be many conversations that would be important for operators to paricipate in! 

We look forward to seeing EVERYONE at the PTG in October! Registration is currently open and free to everyone who would like to attend. If you haven’t signed your team up yet, do it by August 26!

How to Have a Successful PTG as an OpenStack Operator

Myth: Project Teams Gatherings (PTGs) are working events organized by the OpenInfra Foundation only for OpenStack developers to collaborate on an upcoming release. 

Let’s break that down. 

Project Teams Gatherings (PTGs) are working events organized by the OpenInfra Foundation: CORRECT. PTGs are only for OpenStack developers to collaborate on an upcoming release: WRONG

While PTGs are for OpenStack developers, attendees form a broader group to make the event successful. This includes operators who are running projects in production, plan to run the project in the future or projects they have feedback for.  Even if you are running an older release of OpenStack, your feedback and questions and opinions are still incredibly valuable!

Who should attend a PTG? 

First of all, any open source project is welcome to participate in the PTG. Typically, the majority of attendees are from an OpenInfra project—OpenStack, Kata Containers, StarlingX—but other adjacent communities are also invited and encouraged to attend. 

It’s also not limited to upstream contributors. Any team can participate in the PTG—that means that its not just projects, its also SIGs, Working Groups, pop-up teams and other forms of collaboration! There are of course the usual suspects that typically attend—contributors from OpenStack, StarlingX, and Kata—but subteams within those projects also can meet (RBAC pop-up, Nova, Neutron, Manila, Large Scale SIG, etc), in addition to Foundation level working groups like the Edge Computing Group and Diversity and Inclusion Working Group who also participate.

These teams group source their agendas after they sign up to attend, so if you are interested in bringing up a topic with them, please do! Many of the teams use etherpads to collect topics and then gauge interest levels of people planning to attend before organizing the dicussion topics into a schedule. While they are doing this collection of topics, they are also signing up for time + space to meet, so if there is a topic you want to talk about but you can’t be there, let them know in the etherpad so they can try to accomodate your schedule! 

You are encouraged to attend as many groups meetings as you would like. Different teams will be meeting throughout the week. As an example, it’s totally okay to attend  Nova discussions in the morning before headed to the Zuul room after lunch and then pop over to the Cinder room for a particular discussion on CEPH that you are interested in. Teams try to expose the topics they are actively talking about and planning to talk about next via the PTGBot- more on that later.

Specifically, how should OpenStack operators participate at PTGs?

Of course there will be topics that are more specific to operations and using OpenStack clouds that might not fit into any particular team or group signed up, the OpenStack operators are a team and are encouraged to sign up for time/space just like any other team. You can group source and manage your own agenda and use the PTGBot just like any other team. If there are topics you want particular people to participate in, you can invite representatives from those projects to join in those topics as well. 

The key to success here is to be as open and flexible as possible. Sometimes you might need to hop into a different room to attend a particular discussion and sometimes you might need to poke at people to come to the critical mass you already have assembled for a topic. What’s important to remember is that we are all just subteams hoping to make open source and OpenStack a better projects. 

I’ve reached out to a few of the project teams who are participating at the October PTG to highlight the impact operators can have on already scheduled meetings. I encourage you to follow along as we hear what these teams have planned and what you can get out of attending the October PTG. 

We look forward to seeing EVERYONE at the PTG in October! Registration is currently open and free to everyone who would like to attend. If you haven’t signed your team up yet, do it now by August 26!

Have questions? Ping me on the OFTC network on IRC at diablo_rojo.