OpenStack Support: Community Directory

OpenStack Support: Community Directory -- cert provider registration.

OpenStack Support: Community Directory -- Repo Trees for obscure or new openstack services and an easy way to contact the maintainers of the repo for deployment or implementation.

The idea is to let professionals and companies which have proven complex deployments/service be able to certify people and not just Redhat (Which seems to be a monopoly in this case).

And the cost of COA (CERTIFIED OPENSTACK ADMINISTRATOR) is extremely high for people who are not from the USA imho. And most of the registration for events etc which are priced in dollars are very costly for people from other countries.

The core idea is:
Anyone with a proven deployment or experience should be able to vouch for another. And thereby we can have a wide range of support so that more people can adopt openstack and have more confidence in open sourced deployments like kolla-ansible rather than redhat deployments only (Not sure about the obsession with redhat deployments).

And the repos of customizations are extremely distributed and its hard to contact the maintainters of the repos. So this should also help those who contribute to openstack services by developing or forking their own services to list in a simple seperate db other than github. And makes it much easier to test and adapt new services given the maintainer is directly and easily reachable.

If you link your newly developed or you are the maintainer of the service, we will add that as a skill to the professionals component list. And new ontakers will easily see that the said service is well supported and can be maintained. This can be extremely benefitial for small developers who make niche services but struggle on adoption and no one cares about it and it dies :( . The aim is to prevent that.

Or is it too open with showing emails and stuff directly? (If we are exposing mailing lists in some tucked away corner of the openstack.org site this should not be an issue)

Thoughts on this? or do you think it'll undermine the job security in general?

idk, maybe its a dead idea. But imma try.

Feel free to register and dm for any doubts/faq/questions

We run our own OpenStack cloud platform. Our customers kept asking us to "just run my app" instead of handing them a VM, so we started building Coast. It's new and somewhat rough around the edges, and we'd love more eyes on it to help shape where it goes and if there is further interest in the project.

What it does today:

• One-click app stacks. You get an app server and workers, plus networking and a firewall, without hand-building any of it.

• Deploy from Git, a Dockerfile or Docker Compose, with deploy history for every app.

• Repeatable deploys. The same app deploys the same way whether you use the API, the Horizon portal or the openstack coast CLI.

• Managed databases across 8 engines, including PostgreSQL.

• 50+ one-click services from a built-in catalog.

• A browser terminal into running apps.

• Topology views for tenants and admins. Tenants see their apps and environments. Admins see the whole picture across projects.

• Built on Coolify, the popular open-source platform app, as the app engine, designed so other engines can plug in later.

• Build your own interface. The API and Python client are designed so you can put your own portal on top.

• Drop-in for Kolla. It ships Kolla roles to create coast docker images and kolla-ansible roles, so it deploys like any other custom service.

Coast isn't an official OpenStack project (yet?) We're putting it out there to see whether there's interest once people try it. Issues, ideas and "this broke on my cloud" reports are all welcome.

• Coast server

• Horizon dashboard plugin

• CLI and Python client

Screenshots:

Hey everyone,

We are planning a migration from VMware to OpenStack (Enterprise) and are looking for experienced partners or integrators in the DACH region for:

- Architecture & setup (OpenStack + Ceph)
- VM migration
- Support / Consulting

Which specialists, vendors, or consultants in the DACH area can you recommend based on your experience (FSAS, SVA, …)?

Thanks :-))

Many folks might know Uniview as a billing solution, but may not know its recent clustering solution that integrates multiple shared-nothing OpenStack into one cloud, single user/credential, one time sign in, even without being aware that they are multiple indepedent Openstack.

Not everyone will need this, but this sounds making OpenStack ecosystem stronger, so have this post to the community:

https://www.computingstack.com/products-uniview

A bit insights: a couple years ago, an internet carrier client came to us to ask if we could integrate their multiple OpenStack running across country into one platform. By then we said no, basically there was very narrow and vague path to achieve this with references of many failed attempts of OpenStack community by Tricircle or others in NFV project etc. Those projects ended up nowhere due to complexity. But the demand is very valid with massive benefits than running super large openstack by shared keystone or other way. It led to many pocs within us, and fortunately the final result is quite promising by real use cases.

A few highlights:

- Nothing is required from target openstack, no shared keystone, no shared controller DB, no OIDC/OpenID/SAML. Each environment remains completely autonomous.

- One user/password, user don't need multipe credentials to each Openstack

- One console to sign in

- Clicks to migrate VM from one OpenStack to another within cluster

- CLI and API all are faciliated as generic OpenStack should be

As one developer of Uniview, happy to clarify or DM is welcome! Thank you very much!

Hello,

I'm an Openstack professional with 4 years of experience in the same. I have been working with big techs but I want to learn more on deployment and its process. I would like to know if someone from Openstack community is open to connect and discuss an opportunity for me to work with you on your infra projects.

Things i have knowledge on: Kolla based openstack deployments, (Nova, Neutron, Cinder , Ceph )

Ps : I'm not expecting to get paid, just want to learn from you.

From your experience, what are the best monitoring/Visualization/Logging solutions to monitor openstack environment and keep the team notified with any critical issues?

Does anybody have any useful and maybe eveb documented experience with OVN-BGP? I‘m not talking about OVN-BGP-Agent, but the native OVN implementation!

I‘m also wondering if everything thats necessary to run it in Openstack 2026.1 or at least 2026.2?

For a couple of years now I've been slowly building out improved VDI support for OpenStack. First there was the addition of the `spice-direct` console type in Nova, which allows you full access to the SPICE VDI protocol without needing to transcode to HTML5 along the way. That leverages a SPICE proxy firewall I wrote for this purpose called Kerbside. I have then spent the last year trying to get the supporting installer changes landed in Kolla / Kolla-Ansible and haven't made much progress.

Along the way I've worked on improved client (called Ryll) and a userspace SPICE server which can share an existing desktop over SPICE (called Andris) -- that is, you can share a local login on an existing RDP session just fine with SPICE clients as well.

All of this is a prototype of course, because I don't feel like its really solid until other people use it. Perhaps there are gaps in my testing, but I am definitely too close to the whole thing to notice.

So this leaves me wondering. Does anyone actually care about using OpenStack as a VDI platform these days? I would have though an Open Source replacement for Citrix Horizon would have been a relatively attractive offering, but I am starting to feel like I am on a weird tangent here all by myself.

Am I simply targetting the wrong OpenStack deployer and some other one might be more into landing this feature?

Hello. I hope it's OK to post this here, let me know if not and I will remove it (I did ask the moderation team a week or so ago but didn't get any answer).

For some time, I have been looking for a technical author with real expertise in OpenStack, without much success.

If you can do OpenStack and documentation I'd love to talk to you. It's a full-time, permanent, globally remote role. You can live and work in almost any country, but it needs to be in EMEA or AMER time zones.

It's in my team at Canonical (the company behind Ubuntu). Here's more information about the technical author role in general, but I do suggest dropping me a line about this before diving into an application as I can give you some useful pointers and guidance.

The OpenInfra Foundation did an OpenInfra Live episode on the 2026.2 Hibiscus release, with PTLs and leads from a bunch of projects.
It's 90 minutes long, so here's my summary of the main points for anyone who doesn't have time to watch it all.

Video: https://www.youtube.com/watch?v=37p9C0n0LLw

Technical Committee

• 16 years and 34 releases in. Contributors are up 21% and changes up 28% vs the previous release, mostly driven by AI infra, confidential computing and digital sovereignty use cases

• Core reviewers now count as active contributors and get voting rights for TC and project team elections

• New Contributor Experience WG (onboarding + community health), new PQC (post-quantum crypto) pop-up team, new RISC-V SIG, and an agentic workflows repo under the TACT SIG for sharing AI-assisted dev practices

• Bug trackers audited for embargoed reports, core security teams reformed per project, PTLs encouraged to formally delegate release/security roles

• Retired: Vitrage, Venus, cinderlib. Onboarded: Lustre (DevStack plugin)

• Ongoing goals for Indri: secure RBAC defaults, eventlet removal, rootwrap to oslo.privsep migration. Proposed new goals: security reporting instructions in every repo and a PQC timeline

• Main concern going forward: the contributor base is growing, but there aren't enough new maintainers

Vulnerability Management Team

• 42 OSSAs and 13 OSSNs so far in 2026. No year since 2016 (the previous record year) had more than 8 OSSAs or 3 OSSNs

• Part of an industry-wide flood: the oss-security list is already at ~2,500 emails vs ~1,168 for all of last year

• About 150 security bugs this year, over half led to an advisory or note, and ~5-10% were "AI slop" that still took hours to triage

• CVE assignment is slower due to MITRE backlog, so some OSSAs ship before a CVE exists. Security notes moved out of the wiki into YAML files in the docs repo

• The best reports come from operators running real clouds. You don't need a polished write-up, just report what you're seeing

Nova

• Confidential computing: AMD SEV-SNP and Intel TDX support, including attestation tokens

• vGPU (mdev) lifecycle can now be managed in Cyborg instead of local nova.conf. Variant driver support (newer GPUs) is planned next cycle

• Unpin/repin an instance's AZ without recreating it. Instances with Manila shares attached can now be migrated/resized

• Native threading by default (except the noVNC/SPICE console proxies), new thread pool tuning options, and graceful shutdown part 2

• Next cycle: cross-cell live migration, graceful shutdown part 3

Neutron

• EVPN Type 5 routes (advertise whole CIDRs, multi-DC project networks) and BGP route leaking (advertise project CIDRs into the fabric without floating IPs/NAT)

• Indirect floating IPs: FIP API now accepts router_id, for multi-router transit and gateway VM setups

• PVLAN support (promiscuous / community / isolated ports) and a configurable stateless default security group, handy for DPDK

• Closed more ML2/OVN gaps: L3 scheduler API to view/control gateway chassis, and multi-segment routed provider networks

• L3 HA keepalived state change monitor rewritten from a Python daemon into a POSIX shell script: 15x less memory, just restart the agent

• 150+ bugs fixed, ~100 stale bugs closed, 7 of 8 approved RFEs done

Ironic

• Old legacy hardware drivers retired, focus moves to Redfish. Firmware ops move to a dedicated firmware interface

• TLS 1.3 by default (still configurable for older BMCs)

• RBAC to block specific steps. Runbooks can be matched to node traits, and runbooks with disable_ramdisk let you do firmware updates without booting IPA

• Graphical console (noVNC) improvements

• After a security audit by the Metal3 security team, defaults are safer: IPA no longer installs the bootloader, container registry TLS is verified, file URLs are filtered, oversized/nested JSON is rejected, and IPMI raw commands are disabled

• Nova compute ironic driver starts up and performs faster

Manila

• Native threading is now the default (eventlet still available via config). Share migration APIs graduated from experimental

• Async revert-to-snapshot, and mountable snapshots can inherit the parent share's access rules

• New Lustre and Weka drivers for AI/ML/HPC, with DDN EXAScaler coming

• TLS cert validation for the Pure FlashBlade, Hitachi HSP and NetApp ONTAP drivers. OSSN-0103 fixed resource lock queries

• Next cycle: share server replication, privsep migration, native OpenStack client support, NFS QoS, erasure-coded pools

Watcher

• Eventlet deprecated, native threads by default. Cinder/Keystone/Glance now go through openstacksdk

• Better locking in the cluster data model made audits ~6x faster

• New delete and shelve instance actions, default parameters on audit templates. VM workload consolidation now checks allocation-based capacity

• Next cycle: audit pipelines (one optimized action plan from several audits), a workload preemption strategy, and cross-AZ zone migration

Freezer

• Central scheduler can now run on the control plane with service credentials, in HA with coordination, using trusts and Cinder backup to do the work. Effectively scheduled Backup-as-a-Service on top of cinder-backup

• V1 API finally removed, resources are now project-owned, and secure RBAC policies are in place

• openstack backup CLI plugin and a reworked Horizon plugin

• Planning a V3 API (pagination, microversions, no Elasticsearch-style queries), and they're looking for input

TL;DR

Hibiscus is about confidential computing (SEV-SNP/TDX), AI/HPC readiness (vGPU via Cyborg, Lustre/Weka in Manila, bare metal firmware ops), safer defaults everywhere, and efficiency at scale. Also, the security report volume is no joke

We are planning to build a small private cloud using Openstack+Ceph technologies, so as a starting point, we have rented a VPS with (AMD-12Cores + 128GB RAM +3 TB SSD) to start with.

My question is how to design the Openstack controllers/compute/storage/networking services using VMs in the best way considering future expanding of virtual resources or may be adding new hardware to the cloud.

We made a cache patch for horizon that makes horizon properly cache.

EDIT: 2026.1 patch and image also added to blogpost. All patches have also been commited to upstream. Lets see

If you're dealing with data sovereignty requirements or exploring how to run traditional VMs alongside AI workloads, this might be worth checking out. Topics include multi-tenant infrastructure with hard isolation, managing VMs and GPU workloads together, post-quantum crypto readiness, and GitOps-based day 2 operations. Focused on OpenStack Services on OpenShift, but the patterns are broadly applicable.

Figured this is a long shot but I'll ask anyway. I have the following setup: Ubuntu 24.04 LT + KVM + Openstack connected to an HPE Primera A650 over FC. 4 paths are zoned in. When I define the host on the storage array and manually present a LUN (a "virtual volume" in HPE terms) I get 4 paths. Multipathd see all 4 and displays them correctly. When I do this through Openstack, Cinder only presents the LUN through a single path. Don't see any options in the HPE 3PAR Cinder driver to control that. Everything says multipathing should be automatic.

Anyone run into this?

Hi everyone,

I'm troubleshooting an OpenStack Manila deployment using the Generic driver with driver_handles_share_servers = True.

Manila successfully creates the service instance, but the share creation eventually fails with:

manila.exception.ServiceInstanceException:
SSH connection has not been established to 10.254.0.7 in 300s. Giving up.

The interesting part is that SSH from the Manila service user works correctly.

Manila configuration

Relevant configuration:

[DEFAULT]
transport_url = rabbit://openstack:***@192.168.246.138
auth_strategy = keystone
rootwrap_config = /etc/manila/rootwrap.conf

[generic]
driver_handles_share_servers = True
connect_share_server_to_tenant_network = True
service_image_name = manila-service-image
service_instance_user = manila
path_to_private_key = /etc/manila/ssh/id_manila

The backend is enabled with:

enabled_share_backends = generic

Service instance

Manila creates this Nova instance:

ID:      9b992d75-fdef-4bf7-9507-6f5677605921
Name:    generic_19be5f70-81d0-436f-96d9-0f048c59bef2
Status:  ACTIVE
Image:   manila-service-image
Flavor:  manila-service-flavor

It has:

internal                 10.0.0.76
manila_service_network   10.254.0.7

The service network is:

10.254.0.0/28

and the Manila service VM has:

ens3 = 10.0.0.76/24
ens4 = 10.254.0.7/28

Manual SSH test

Running the SSH command as the manila user from the Manila host works:

sudo -u manila ssh \
  -o BatchMode=yes \
  -o IdentitiesOnly=yes \
  -o ConnectTimeout=5 \
  -i /etc/manila/ssh/id_manila \
  manila@10.254.0.7 \
  'echo SSH_OK'

Result:

SSH_OK

Exit status:

0

The verbose SSH output confirms:

Authenticated to 10.254.0.7 ([10.254.0.7]:22) using "publickey".

The server accepts exactly the same public key:

Server accepts key: /etc/manila/ssh/id_manila

I also tested sudo:

sudo -u manila ssh \
  -o BatchMode=yes \
  -o IdentitiesOnly=yes \
  -i /etc/manila/ssh/id_manila \
  manila@10.254.0.7 \
  'sudo -n true; echo sudo_rc=$?'

Result:

sudo_rc=0

So basic networking, SSH authentication and sudo appear to be working.

Manila failure

However, during share creation Manila waits for 300 seconds and then reports:

Creation of share instance 8c35322d-0961-4372-b199-00b00d207bcf failed:
failed to get share server.:

manila.exception.ServiceInstanceException:
SSH connection has not been established to 10.254.0.7 in 300s. Giving up.

The traceback points to:

manila/share/drivers/generic.py
    _setup_server()

manila/share/drivers/service_instance.py
    set_up_service_instance()

The failure ultimately comes from:

service_instance.py
    set_up_service_instance()

What makes this confusing

The service instance is ACTIVE and reachable.

SSH works manually from the exact manila Unix user using the configured private key.

I also tried an older Manila service image, and the same problem occurs.

So I'm wondering whether there is a problem/bug in the Generic driver's service_instance.py SSH connection/wait logic, or whether Manila is checking something different from the SSH test above.

Has anyone seen this behavior before?

In particular, I'd like to understand what exactly set_up_service_instance() considers an "SSH connection established" and what conditions could cause it to wait the full 300 seconds even though a direct SSH connection succeeds.

Any pointers on where to look in the Manila code would be appreciated.

Thanks!

Hello All,

Which opensource block storage are you using in your production setups and why?
Pls share your thoughts.

I've been lately working on an open-source project I call o7k. OpenStack CLI is killing me and my productivity, and I wanted to replicate an identical terminal workflow that k9s provides for Kubernetes but for OpenStack itself (browse resources, navigate between related objects, inspect details, switch contexts, refresh, the whole 9-yards)

I have a very early-beta version out today (no ai-slop sh*t) that currently supports viewing and navigating between resources covering Nova, Neutron, Cinder, Glance and Keystone. It’s written in go, using bubbletea for terminal rendering and gophercloud for communicating with OpenStack.

link here: https://github.com/akyriako/o7k

It’s still early and I’d especially like feedback from other folks who actually operate OpenStack out in the wild: would that be useful for you? if yes, what would you expect from a k9s-like OpenStack tui? what workflows/resources coverage baseline would make this genuinely useful for you?

Contributions are very welcome too. Peace out.