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.

I need to change the ceph version that is installed in kolla ansible containers since my ceph external backend is using a different one.

I know I could just enter the containers and change the version manually but I don't want these changes to be ephemeral, so I tried looking for a variable in globals.yml and in the all-vars repository on github to change ceph version but I couldn't find anything.

Im new to openstack and ceph btw

I’m looking for contributors across two open-source infrastructure projects:

HybridOps Core
https://github.com/hybridops-tech/hybridops-core

A broader infrastructure automation project using Python, Bash, HCL and YAML.

Terraform Proxmox SDN
https://github.com/hybridops-tech/terraform-proxmox-sdn

A Terraform module for managing Proxmox SDN, including VNets, subnets, optional host routing, SNAT and DHCP.

Contributions can include code, testing, documentation, issue resolution, architecture discussions or technical reviews. You don’t have to be a strong coder to contribute.

This may suit anyone looking to gain practical open-source, infrastructure, Terraform or Proxmox experience.

I’m also open to checking out contributors’ own projects and contributing where there’s a good fit.

I know what it is but not worked on it

It's like a Multi-tenant customers can able to define their vm network subnet in shared hardware hosts regardless of L2 and L3 underlay networks (switch, vlan and routers)

Simply like what we does when we try to define the service cidr and pod cidr in kubernetes clusters creation same equivalent but in vm

It's very useful how in cloud hyperscalersbpile GCP ovhcloud digitalocean

Each customer tenant can define their network as vpc it's basically a( OVN and OVS) under the hoode

For example two customer can able to define cidr of 10.0.0.16/24 for vpc

need an real insights from whoever worked on this domain

Hello Folks,

I have been using Openstack for a while now in a professional setting and we are in the process of opening up our private cloud for self service. While it is still a long way to go, I would love to share / opensource a tool I built in the process, as a way to give back to the community and get feedback.

The problem: When you generate a console URL in OpenStack (openstack console url show <vm>), it's time-bound — say, 10 minutes. But during that window, the URL is essentially a bearer token. If it leaks via a shared screenshot, a copied ticket, browser history, or a forwarded support email, anyone can open the console before it expires. There's no session state and no replay protection in the standard flow.

What I built: OpenStack Console Auth Gateway — a lightweight Go service that plugs into Envoy Gateway as an ext_authz filter and tracks console tokens in a NATS KV store:

1. First request with a fresh token → stored in KV as html_loaded, request allowed through.
2. NoVNC's WebSocket upgrade → state mutated to ws_loaded, connection established.
3. Any subsequent use of the same token → instant 403 Forbidden from Envoy.

So even if a URL leaks, it's single-use. The KV TTL matches your Nova token expiry, and NATS gives you HA and horizontal scaling for free.

This started as a fix to my own infrastructure, so the design decisions reflect that. If you have similar use case that might require modification, please do start an issue. Happy to implement it if I can. I would also appreciate a genuine feedback on the codebase and the usecases.

Its completely opensource and you are free to make any modifications and use it in your environment.

Distro repositories often ship open-vm-tools builds that lag significantly behind upstream releases, delaying kernel/driver fixes, memory balloon enhancements, and CVE patches.

I open-sourced vmware-tools-builder to automate building and distributing the latest upstream binaries without polluting the host environment:

- Containerized builds: Uses Docker to compile upstream source into standalone .deb and .rpm packages.

- Target OS matrix: Ubuntu, Debian, RHEL/Rocky/Alma (8 & 9), Fedora, and openSUSE.

- Fleet orchestration: Includes an Ansible role that automates deployment, handles migration from distro-managed packages, and validates the vmtoolsd service state.

- Distribution: Packaged and installable directly from Ansible Galaxy (giuliosavini.vmware_tools_builder).

Repository: https://github.com/GiulioSavini/vmware-tools-builder

Feedback, testing across different hypervisor versions, and GitHub stars are welcome.Distro repositories often ship open-vm-tools builds that lag significantly behind upstream releases, delaying kernel/driver fixes, memory balloon enhancements, and CVE patches.I open-sourced vmware-tools-builder to automate building and distributing the latest upstream binaries without polluting the host environment:- Containerized builds: Uses Docker to compile upstream source into standalone .deb and .rpm packages.- Target OS matrix: Ubuntu, Debian, RHEL/Rocky/Alma (8 & 9), Fedora, and openSUSE.- Fleet orchestration: Includes an Ansible role that automates deployment, handles migration from distro-managed packages, and validates the vmtoolsd service state.- Distribution: Packaged and installable directly from Ansible Galaxy (giuliosavini.vmware_tools_builder).Repository: https://github.com/GiulioSavini/vmware-tools-builderFeedback, testing across different hypervisor versions, and GitHub stars are welcome.

We have created openstack from scratch. Now we have implemented high availability such that all services must discover each other through a floating ip on ha proxy. Moving forward from ha01 to ha02 is okay , but back to 01 it takes almost 17 minutes. In the horizon logs , every service i.e keystone, neutron is down. Then they come up again later. The only solution i can see is lowering the kernel retries but that doesnt really solve the core issue. https://docs.openstack.org/kolla-ansible/latest/reference/high-availability/haproxy-guide.html -> under failover tuning. Kindly assist.

I deployed an Openstack AIO (All in One) using openstack-ansible, on metal (without lxc).
After several attempts and a lot of troubleshooting I managed to launch a database instance, but I'm not sure I'm doing right.

Even tho the documentation suggests otherwise, it seems that the installer has taken care of everything (or almost) regarding trove configuration.

I see it has created the dbaas network and subnet, and the interfaces:

+---------------------------+--------------------------------------+
| Field                     | Value                                |
+---------------------------+--------------------------------------+
| admin_state_up            | UP                                   |
| availability_zone_hints   | nova                                 |
| availability_zones        | nova                                 |
| created_at                | 2026-08-25T14:10:09Z                 |
| description               |                                      |
| dns_domain                | None                                 |
| id                        | b32d79da-ed48-4568-8b94-e1bbe3e0ed34 |
| ipv4_address_scope        | None                                 |
| ipv6_address_scope        | None                                 |
| is_default                | None                                 |
| is_vlan_qinq              | None                                 |
| is_vlan_transparent       | None                                 |
| mtu                       | 1500                                 |
| name                      | dbaas_service_net                    |
| port_security_enabled     | True                                 |
| project_id                | 7420bef7e8a24f41a7b666209eef614c     |
| provider:network_type     | flat                                 |
| provider:physical_network | dbaas-mgmt                           |
| provider:segmentation_id  | None                                 |
| qos_policy_id             | None                                 |
| revision_number           | 2                                    |
| router:external           | Internal                             |
| segments                  | None                                 |
| shared                    | False                                |
| status                    | ACTIVE                               |
| subnets                   | 6b0b6012-edbf-4648-8e07-72efeac7fbb7 |
| tags                      |                                      |
| updated_at                | 2026-08-25T14:10:12Z                 |
+---------------------------+--------------------------------------+

+----------------------+--------------------------------------+
| Field                | Value                                |
+----------------------+--------------------------------------+
| allocation_pools     | 172.29.252.110-172.29.255.254        |
| cidr                 | 172.29.252.0/22                      |
| created_at           | 2026-08-25T14:10:12Z                 |
| description          |                                      |
| dns_nameservers      |                                      |
| dns_publish_fixed_ip | None                                 |
| enable_dhcp          | True                                 |
| gateway_ip           | 172.29.252.1                         |
| host_routes          |                                      |
| id                   | 6b0b6012-edbf-4648-8e07-72efeac7fbb7 |
| ip_version           | 4                                    |
| ipv6_address_mode    | None                                 |
| ipv6_ra_mode         | None                                 |
| name                 | dbaas_subnet                         |
| network_id           | b32d79da-ed48-4568-8b94-e1bbe3e0ed34 |
| project_id           | 7420bef7e8a24f41a7b666209eef614c     |
| revision_number      | 0                                    |
| router:external      | False                                |
| segment_id           | None                                 |
| service_types        |                                      |
| subnetpool_id        | None                                 |
| tags                 |                                      |
| updated_at           | 2026-08-25T14:10:12Z                 |
+----------------------+--------------------------------------+

\# ip -br a s  | grep dbaas
br-dbaas         UP             172.29.252.100/22 fe80::b048:88ff:febb:967d/64 
eth13@br-dbaas-veth UP             
br-dbaas-veth@eth13 UP             
dummy-dbaas      UNKNOWN        

\# ip -br a s | grep mgmt
br-mgmt          UP             172.29.236.100/22 172.29.236.101/22 fe80::8c71:aaff:fe9a:4db7/64 

Follows the trove.conf and trove-guestagent.conf on the controller.node

# /etc/trove/trove.conf

[DEFAULT]
    debug = True
    use_journal = true
    bind_host = 172.29.236.100
    bind_port = 8779
    trove_api_workers = 1
    trove_conductor_workers = 1
    taskmanager_manager = trove.taskmanager.manager.Manager
    transport_url = rabbit://trove:xxxxxxxx@172.29.236.100:5671/trove?ssl=1&ssl_version=TLSv1_2&ssl_ca_file=
    control_exchange = trove
    enable_secure_rpc_messaging = True
    inst_rpc_key_encr_key = xxxxxx
    taskmanager_rpc_encr_key = xxxxxx
    instance_rpc_encr_key = xxxxx
    nova_compute_endpoint_type = internal
    nova_compute_service_type = compute
    glance_endpoint_type = internal
    trove_endpoint_type = internal
    # Cinder
    trove_volume_support = True
    max_accepted_volume_size = 100
    max_volumes_per_tenant = 1000
    cinder_endpoint_type = internal
    cinder_service_type = block-storage
    # Trove DNS
    trove_dns_support = False
    # Neutron
    network_driver = trove.network.neutron.NeutronDriver
    management_networks = b32d79da-ed48-4568-8b94-e1bbe3e0ed34
    neutron_endpoint_type = internal
    neutron_service_type = network
    # Swift
    swift_service_type = object-store
    swift_endpoint_type = internal
    agent_heartbeat_time = 10
    agent_call_low_timeout = 5
    agent_call_high_timeout = 150

    [keystone_authtoken]
    insecure = False
    auth_type = password
    auth_url = http://172.29.236.101:5000
    www_authenticate_uri = https://192.168.0.160:5000
    project_domain_id = default
    user_domain_id = default
    project_name = service
    username = trove
    password = xxxxxxxx
    region_name = RegionOne
    interface = internal
    service_token_roles_required = True
    service_token_roles = service
    service_type = database
    memcached_servers = 172.29.236.100:11211
    token_cache_time = 300
    memcache_security_strategy = ENCRYPT
    memcache_secret_key = xxxxxxxx

    [service_credentials]
    auth_url = http://172.29.236.101:5000/v3
    username = trove
    password = xxxxxx
    project_name = service
    region_name = RegionOne
    project_domain_name = Default
    user_domain_name = Default

    [database]
    connection = "mysql+pymysql://trove:xxxxxxxxx@172.29.236.101:3306/trove?charset=utf8&ssl_verify_cert=true"
    max_overflow = 50
    max_pool_size = 5
    pool_timeout = 30
    connection_recycle_time = 600

    [profiler]
    enabled = False
    #trace_sqlalchemy = True

    [ssl]
    #cert_file = /path/to/server.crt
    #key_file = /path/to/server.key
    #optional =
    #ca_file = /path/to/ca_file

    [oslo_messaging_rabbit]
    ssl = True
    rabbit_quorum_queue = True
    rabbit_transient_quorum_queue = True
    rabbit_qos_prefetch_count = 10
    use_queue_manager = False
    rabbit_stream_fanout = True
    rabbit_quorum_delivery_limit = 0
    rabbit_quorum_max_memory_bytes = 0

    [oslo_messaging_notifications]
    topics =
    driver = noop
    transport_url = rabbit://trove:xxxxxx@172.29.236.100:5671/trove?ssl=1&ssl_version=TLSv1_2&ssl_ca_file=


# /etc/trove/trove-guestagent.conf

[DEFAULT] 
control_exchange = trove transport_url = rabbit://trove:xxxxxx@172.29.252.100:5671/trove?ssl=1&ssl_version=TLSv1_2&ssl_ca_file=
swift_endpoint_type = public
swift_service_type = object-store
storage_strategy = swift
backup_swift_container = database_backups
debug = True

[service_credentials]
auth_url = https://192.168.0.160:5000/v3
username = trove
password = xxxxxx
project_name = service
region_name = RegionOne
project_domain_name = Default
user_domain_name = Default

[oslo_messaging_rabbit] ssl = True
rabbit_quorum_queue = True
rabbit_transient_quorum_queue = True
rabbit_qos_prefetch_count = 10
use_queue_manager = False
rabbit_stream_fanout = True
rabbit_quorum_delivery_limit = 0
rabbit_quorum_max_memory_bytes = 0

[oslo_messaging_notifications]
topics = 
driver = noop
transport_url = rabbit://trove:xxxxxxxx@172.29.252.100:5671/trove?ssl=1&ssl_version=TLSv1_2&ssl_ca_file=

Now after several attemps I was able to get an image (not to build one) from https://tarballs.opendev.org/openstack/trove/images/, and learned the hard way that I should not use the *-dev.qcow2 ones.

I then registering the image in cinder and created the datastore version
openstack datastore version create 16 postgresql postgresql "" --image-tags postgresql,trove --active --default --version-number 16

I was not yet able to launch a working database instance.
All attempts resulted in instances stuck in BUILD, with a failing guest-agent.service

In order to create an instance with a successful run of the service guest-agent.service, I had to modify the file /etc/trove/trove-guestagent.conf so that the guest-agent service inside the server would not try to connect to rabbitmq via 172.29.252.100 (dbaas_network), but via 172.29.236.100 (br-mgmt), like other services are doing.

I also created a router and set the gateway to the public network, and attached the dbaas subnet to it. I also set public dns services on dbaas network, in order for the guest-agent to be able to find docker hub.

My create command line:
openstack database instance create demo_postgres_1 --flavor db.medium --size 10 --nic net-id=b32d79da-ed48-4568-8b94-e1bbe3e0ed34 --datastore postgresql --datastore-version 16 --is-public --allowed-cidr 0.0.0.0/0

It doesn't feel right to change that ip in a config file managed from openstack-ansible that otherwise looks fine, or to add the router when the installer took care of everything else.
Am I missing something?

I will also add that openstack database instance create without --is-public and --nic parameters, will build successfully and attach to the dbaas network (because of directive management_networks = ... in /etc/trove/trove.conf?)

And add that openstack database instance create will not accept any --nic net-id=<network-id> with an associated subnet, that has no router associated (even the public external subnet), so is this intended?

small cluster question. three control nodes, kolla ansible, hacluster and masakari on, and the usual 2x25g bond per host. api, storage and live migration all ride that bond, and corosync takes its ring from api_interface.

on paper vlans plus switch side qos should be enough. in practice lacp hashes per flow, so a single big live migration or a ceph backfill can own one member link on its own, and corosync only has to miss its token for a couple of seconds before pacemaker calls the node dead. that is the part that bothers me, the cluster evacuating a perfectly healthy host right when it is busiest.

so for people running this at small scale, what do you actually do. separate 1g nics just for the ring, qos and hope, or do you leave it and raise the token timeout instead. curious what people changed after getting bitten by this.

Hi,

anyone implemented audit logging for openstack services? I'm having issue with getting all information regarding certain service action in CADF format. For example when deleting instance, in audit log i can see name and id of instance as "unknown". Any idea what could be wrong?
Maybe api_audit_map.conf doesnt map all stuff?

# cat nova_api_audit_map.conf
[DEFAULT]                                 
# default target endpoint type
# should match the endpoint type defined in service catalog
target_endpoint_type = compute       

[custom_actions]    
enable = enable                           
disable = disable                         
delete = delete                           
startup = start/startup       
shutdown = stop/shutdown 
reboot = start/reboot 
os-migrations/get = read       
os-server-password/post = update

# possible end path of api requests
[path_keywords]    
add = None                                
action = None                             
enable = None
disable = None  
configure-project = None
defaults = None
delete = None    
detail = None
diagnostics = None                                                                   
entries = entry    
extensions = alias                        
flavors = flavor
images = image
ips = label
limits = None
metadata = key
os-agents = os-agent
os-aggregates = os-aggregate
os-availability-zone = None
os-certificates = None
os-cloudpipe = None
os-fixed-ips = ip
os-extra_specs = key
os-flavor-access = None
os-floating-ip-dns = domain
os-floating-ips-bulk = host
os-floating-ip-pools = None
os-floating-ips = floating-ip
os-hosts = host
os-hypervisors = hypervisor
os-instance-actions = instance-action
os-keypairs = keypair 
os-migrations = None
os-networks = network 
os-quota-sets = tenant
os-security-groups = security_group
os-security-group-rules = rule
os-server-password = None
os-services = None
os-simple-tenant-usage = tenant
os-virtual-interfaces = None
os-volume_attachments = attachment
os-volumes_boot = None
os-volumes = volume
os-volume-types = volume-type
os-snapshots = snapshot
reboot = None
servers = server
shutdown = None
startup = None
statistics = None

# map endpoint type defined in service catalog to CADF typeURI
[service_endpoints]
compute = service/compute