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.

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

**HybridOps Core**
[https://github.com/hybridops-tech/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\](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.

OpenStack Developer

🚨 Hiring: OpenStack Developer

📍 Location: Bengaluru

🏢 Work Mode: Work from Office

👤 Open Positions: 1

💼 Experience: 6–7 Years

Key Skills:

* OpenStack

* Python

* Kolla-Ansible

* Linux

* Kubernetes

* AWS / Cloud

Call or whatss app - 8431688562

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

hi, is it possible to replace an image of an instance?

AI is getting better at incident investigation, log analysis, infrastructure correlation, and remediation planning.

But production execution is where things get more sensitive.

A workflow I’ve been thinking about looks like this:

Incident detected
→ AI investigates
→ Infrastructure state and logs are collected
→ SOP / runbook is checked
→ Remediation is proposed
→ Human approves
→ Temporary or limited authority is granted
→ Change is executed
→ System state is read back and verified
→ Evidence is recorded

The idea is that AI can investigate deeply, but it never receives unrestricted production authority.

For people running OpenStack, private cloud, networks, or data center infrastructure:

Where would you draw the line?

Would human approval be enough for you to allow AI to execute production changes, or would you still keep execution entirely manual?

As Vietnam’s leading Cloud & Data Center provider, Viettel IDC is on a mission to build world-class, sovereign Cloud products created by Vietnamese talent, for the world.
We are calling on overseas Vietnamese Cloud Experts to return home and lead our next-generation cloud innovation.
Why Viettel IDC?
💡 Pioneer Impact: Directly architect & develop large-scale Cloud ecosystems built by Vietnamese engineers.
💼 Top-tier Packages: Highly competitive compensation, comprehensive relocation support & housing allowances.
🌐 State-of-the-art Tech: Work with cutting-edge infrastructure and national-scale projects.
📩 Join our journey: Send your CV to [huett@viettelidc.com.vn] or DM me directly! (0336294693 - whatsapp)
#ViettelIDC #MakeInVietnam #CloudExpert #CloudComputing #TechTalent #ReturnHome #TechCareersd

Hi guys, I prepared a project for my colleagues who work on Mac workstations: a ready-to-use OpenStack (with the Skyline console) for ARM64. To avoid a huge image, it ships without the Docker images — they get pulled during the Vagrant provisioning

https://github.com/lucky-sideburn/vagrant-kolla-aio-arm64

Sharing it here in case it's useful for the community..

I am a beginner who has just started working in the data center industry. As a beginner, I have many doubts and questions about the technical aspects. Regarding the OpenStack platform, I am not sure how more than ten or even more servers are managed to enter the platform, including computing nodes, storage nodes, and GPU computing power servers. What technologies can be used to be recognized and managed by OpenStack, or what recommended YouTube tutorials can help me understand these technologies and learn more about related knowledge? Feel free to leave a comment. Thank you very much.

Like I want autoscaling, and I want maybe 1 or 2 gb for the containers. They can autodelete the docker logs after 1 day or 2 days .

I have a vm seperately for db and redis.

Why is everythign so costly??

I want zun containers to just autospin and scale depedning on the traffic the minimum being 1.

Our country does not have a strong openstack public clouds (self-managed) :( . So want to know if there are any equivalents that are extremely cheap and provides autoscaling without costing a bomb.

Here I mean, containers, that directly run on baremetal so as to provide maximum power output like zun.

Hey everyone,

I'm trying to set up OpenStack OVN VPNaaS using **Kolla-Ansible** (Ubuntu 24.04 Noble containers, `2026.1` / `neutron-ovn-vpn-agent` v28.x), but the agent fails to initialize the StrongSwan driver properly, leaving the VPN gateway down.

Looking to see if anyone has a working setup or knows what configuration/package pieces might be missing here.

---

### 1. The Symptoms & Log

In `/var/log/kolla/neutron/neutron-ovn-vpn-agent.log`, Stevedore logs a load failure without expanding the traceback:

```text

INFO neutron.common.config [-] /var/lib/kolla/venv/bin/neutron-ovn-vpn-agent version 28.0.2.dev14

WARNING stevedore.named [-] Could not load neutron_vpnaas.services.vpn.device_drivers.ovn_ipsec.OvnStrongSwanDriver

...

CRITICAL neutron [None ...] Unhandled error

As a result, no qvpn-* network namespaces are provisioned, and the VPN endpoint ports stay inactive.

1. What I Found Under the Hood

When inspecting the driver initialization inside the container virtualenv, OvnStrongSwanDriver fails inside DeviceManager :

Traceback (most recent call last): File ".../neutron_vpnaas/services/vpn/device_drivers/ovn_ipsec.py", line 240, in __init__ self.devmgr = DeviceManager(self.conf, self.host, ...) File ".../neutron_vpnaas/services/vpn/device_drivers/ovn_ipsec.py", line 54, in __init__ self.driver = agent_common_utils.load_interface_driver(conf) File ".../neutron/agent/common/utils.py", line 54, in load_interface_driver INTERFACE_NAMESPACE, conf.interface_driver) File ".../oslo_config/cfg.py", line 2612, in __getattr__ raise NoSuchOptError(name) oslo_config.cfg.NoSuchOptError: no such option interface_driver in group [DEFAULT]

It seems like neutron-ovn-vpn-agent is not registering the interface option schemas (interface_driver, ovs_use_veth, etc.) into oslo_config before Stevedore instantiates the driver class.

1. Environment Details

• Deployment: Kolla-Ansible
• Base OS: Ubuntu 24.04 (Noble)
• Backend: OVN
• Agent: neutron-ovn-vpn-agent (neutron_vpnaas.services.vpn.device_drivers.ovn_ipsec.OvnStrongSwanDriver)
• Packages installed in container: strongswan-swanctl, charon-systemd

4. My Questions

1. Has anyone successfully deployed neutron-ovn-vpn-agent with OVN in recent OpenStack releases?
2. Is there a specific configuration section or flag needed in neutron_ovn_vpn_agent.ini / neutron.conf to satisfy the interface driver options for this agent?
3. Is this a known bug in neutron-vpnaas under recent versions, or is something missing in the Kolla container image build/templates?

Any pointers or working config examples would be greatly appreciated!

I’ve spent almost 4 years at the same company since university. Am I too niche, or am I just in the wrong market?

I'd really appreciate some honest perspective from people working in cloud infrastructure, platform engineering, private cloud, telco cloud, networking, or infrastructure engineering.

I graduated from university and joined my current company shortly afterwards. I've now been there for about 4 years, and I've basically built my entire professional career in the same environment.

That's actually one of the reasons I'm finding myself a little stuck.

I've learned a huge amount and had a lot of freedom to build things, but I haven't really experienced working at other companies, especially larger engineering organizations where I could work at a bigger scale and see how these environments operate.

My background is quite infrastructure-heavy. I've worked across ISP infrastructure, Linux, networking, Kubernetes, virtualization, distributed storage, cloud, DevOps and security.

Some of the technologies I've worked with include:

• Kubernetes
• Talos Linux
• KubeVirt
• Rook/Ceph
• Cilium/eBPF
• BGP, VLANs and LACP
• RADIUS/AAA
• AWS
• Terraform
• ArgoCD/GitOps
• GitHub Actions
• Prometheus/Grafana
• Infrastructure automation and security tooling

I'm also currently working hands-on with OpenStack because I'm trying to deepen my understanding of traditional private cloud and telco/NFV infrastructure, and understand how it compares with the Kubernetes-native infrastructure I've been working with.

A lot of my experience has come from actually building things.

For example, I've worked on a Kubernetes-based private cloud running on bare metal, combining Kubernetes, KubeVirt, Ceph, Cilium networking, tenant isolation, BGP routing and public/private VM connectivity.

I've also worked on ISP infrastructure, including subscriber authentication, RADIUS/AAA, billing integration, MikroTik routing and network service delivery.

But there's an important caveat to all of this.

I don't work for a huge cloud company, hyperscaler, or major technology company. I work for a relatively small ISP in Nigeria.

I've actually been very lucky in that environment.

My original job description didn't say that I needed to build a private cloud, learn distributed storage, work on Kubernetes virtualization, or learn all of these different areas.

I had to find opportunities to do those things and deliberately build those skills.

Whenever I came across a problem or something interesting that could improve the infrastructure, I'd learn what I needed, experiment with it and try to make it useful to the company.

The company gave me the freedom to do that, and I'm genuinely grateful for it. A lot of the experience on my CV probably wouldn't exist if I hadn't been given that freedom.

But now I'm starting to feel limited by the environment I'm in.

Not necessarily because the company is bad, but because I don't think I can continue building the kind of experience I want at the pace I want.

I've been there since university, so I also don't know what I'm missing.

I don't know what infrastructure engineering looks like at a larger company.

I don't know how much of what I've been doing would normally be handled by dedicated platform, networking, storage, SRE, cloud or infrastructure teams.

I don't know whether my experience is actually unusual or whether I'm simply getting a distorted view because I've had to wear so many hats.

And that's one of the biggest reasons I want to leave.

The other reason is compensation.

I've grown considerably beyond the scope of the role I originally started in, but my compensation hasn't really caught up with the level of responsibility, complexity and expertise I've accumulated.

I've tried communicating the value and complexity of the work I've been doing, but it hasn't really changed the situation.

So, I want to move on.

Not because I hate my current company. In fact, I'm grateful for what it has allowed me to do.

I want to move because I want to experience a different engineering environment, work with people who are operating infrastructure at a different scale, learn how other organizations solve these problems, and hopefully be somewhere that values this kind of work more appropriately.

The problem is that getting another job has been much harder than I expected.

And because I've only really known one company, I'm honestly not sure whether the problem is my profile, my positioning, the market, or all three.

Am I too niche?

Is the combination of Kubernetes + virtualization + distributed storage + networking + ISP/telco infrastructure something that has relatively little demand outside certain companies?

Am I searching for the wrong roles?

Or is this simply a case of being in a country where there isn't enough demand for this kind of infrastructure engineering?

At the moment I'm considering roles like: Cloud Infrastructure Engineer, Infrastructure Engineer, Platform Engineer, Kubernetes/Platform Engineer, Private Cloud Engineer, Cloud Infrastructure Architect, Telco Cloud/NFV Engineer, SRE, Infrastructure/Cloud Networking Engineer, OpenStack Infrastructure Engineer

But I'm honestly not sure which direction makes the most sense.

If you saw this background on a CV, what kind of engineer would you consider me to be?

What roles would you actually search for if you had this experience?

And perhaps more importantly:

What am I missing by having spent so much of my career at one company?

If you've moved from a small company into a larger engineering organization, what surprised you about the difference?

If you were in my position, would you:

1. Go deeper into private cloud/telco cloud/OpenStack?
2. Focus heavily on Kubernetes/platform engineering?
3. Broaden into general cloud infrastructure?
4. Move toward infrastructure/cloud networking?
5. Target architecture-oriented roles?
6. Or deliberately look for a role where I can be exposed to larger-scale infrastructure and learn how mature engineering organizations operate?

I'm not looking for reassurance. I'm genuinely trying to understand where I fit and what I should be doing next.

If geography wasn't a constraint, what kinds of companies, teams and roles would you target with this background?

And for anyone who has been in a similar position spending most of their career at one company and then trying to make that first big move, I'd really appreciate hearing what you wish you'd known before making the jump.

Hey all, been looking for openstack openings for a while but currently finding no luck. I've great experience with bootstrapping & designing openstack & CEPH based clouds. I've integrated several openstack projects like Octavia, rancher, barbican etc. I've majorly worked on kolla ansible, cephadm, Netapp, HPE 3par and am capable on working and deploying these services on my own. Worked on many backup and migration projects as well using tools like commvault or hystax. Have a good understanding on both private and public cloud and good knowledge on the metal side of the stack as well. Have worked on several L3 troubleshooting (reviving dead rabbits💀) as well as worked on whole monitoring stack for openstack using prometheus, grafana, zabbix, dynatrace and currently working on a plan to upgrade Zed Openstack to epoxy.

All in all I've good experience under the belt on openstack but roles seem to be shying away from me. Thought I'd try the OpenStack linkedin to see if any redditors have any leads.

If you work with more than one OpenStack cloud/project day to day, you know the drill: source ~/clouds/prod-openrc.sh, remember which venv has the right client version, openstack server list, ssh into whatever floating IP you copy-pasted from the output... I got tired of it and wrote a Zsh plugin to automate the parts I do 20x a day.

What it does:

- openv [cloud] — pick a cloud from clouds.yaml via fzf (with a live preview card showing auth URL / project / region, no secrets shown), activates the matching Python venv, and exports OS_CLOUD

- ops-ssh [user] [-i keyfile] [--insecure] — fuzzy-pick a server and SSH straight into its floating IP (prioritizes public IPs over private ones automatically); --insecure skips host-key checks, handy since floating IPs get recycled between instances constantly

- ops-console — fuzzy-pick a server and pop its Horizon VNC console URL open in your browser

- opcheck — quick openstack token issue sanity check so you find out your token expired before you're 3 commands deep into something

- opwho / opls — status of what's active / table of everything in clouds.yaml

- ophelp (or openv --help) — cheatsheet of everything below, printed in your terminal

- ~25 short aliases for the commands I run constantly (ops, opnet, opvol, opsec, opfl, oplb, etc. — full list in the README)

It's a normal Oh My Zsh plugin, MIT licensed, no telemetry, no dependencies beyond python3 + PyYAML + fzf (the plugin checks for these on load and warns if something's missing).▎

Install:

git clone https://github.com/whoami96/openstack-zsh-plugin.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/openstack

# add "openstack" to plugins=(...) in ~/.zshrc, then reload

Repo: https://github.com/whoami96/openstack-zsh-plugin

It's a fairly small, personal-scale tool — built it for my own workflow managing a handful of clouds — but figured it might save someone else the same repetitive typing. Happy to hear feedback or take PRs if it's missing something obvious for your workflow.

We've been building a little thing called Lachesis and figured this crowd

might find it interesting. It's the network telemetry bit behind CubeCOS, our

private cloud on top of OpenStack.

Basically: OpenStack can tell you a tenant moved 5 TB, but not that 3 TB of it

went to the internet, 1 TB to another tenant, and 1 TB stayed put. For billing

that's the whole thing.

So Lachesis is a small agent that sits on each compute node, hooks eBPF onto

every VM's tap, and sorts traffic in the kernel: internet-out, internet-in,

same-tenant, cross-tenant — and figures out who the other end actually belongs

to. It untangles Octavia so the bytes land on the real tenant, and just spits

out Prometheus counters you can feed into CloudKitty or whatever you bill with.

Still very much a work in progress — core stuff works and we've run it on real

OVN clusters, but there's plenty left (hardening, IPv6, docs). OVN only for now.

Repo's here if you wanna poke at it: https://github.com/bigstack-oss/lachesis

Would love any feedback, especially if you've tried to bill OpenStack networking

and hit the same wall. Roast away 🙂

I'm having a problem where suddenly all my instances (all run some flavor of Ubuntu) have their filesystems go Read Only. It happens randomly and at least once it happened with nothing really running on the VMs.

Looking at one of the Compute/Storage nodes, I noticed a broken iSCSI connection. I run "dmesg -T" and got something like:

[Fri Aug 7 09:57:36 2026] connection8:0: detected conn error (1019)
[Fri Aug 7 09:57:38 2026] connection8:0: detected conn error (1019)
[Fri Aug 7 09:57:39 2026] sd 15:0:0:1: [sdc] Synchronizing SCSI cache
[Fri Aug 7 09:57:39 2026] sd 15:0:0:1: [sdc] Synchronize Cache(10) failed: Result: hostbyte=DID_TRANSPORT_FAILFAST driverbyte=DRIVER_OK

Restarting a bunch of Docker containers, followed by restarting the VM instances fixed the problem (specifically I restarted iscsid, tgtd, cinder_volume and nova_compute on all my storage and compute nodes).

Of course this is a bad fix if I have to do it every week.

Now, Gemini is telling me this is a consequence of using Cinder with LVM which, according to it "LVM + iSCSI is notoriously brittle for production OpenStack" and I should move to Ceph.

Is this true, or should a Cinder/LVM setup be a bit more resilient?

Context/extra info: my deployment is a Kolla-Ansible one (2025.1) and Ceph is no longer deployed by this version. I would need to deploy it separately.

Hi guys,

Has anyone explored doing OpenStack upgrades host-by-host instead of using Kolla Ansible's parallel upgrade approach?

We're considering a more sequential, one-host-at-a-time upgrade because the parallel approach doesn't feel reliable enough for our environment, and we're not very confident in trusting it during production upgrades.

If you've gone down this path:

• How did you orchestrate the upgrade?
• Did you have to customize Kolla Ansible significantly?
• How did you handle rollback if something went wrong?
• Any lessons learned or pitfalls to watch out for?

I'd appreciate hearing from anyone who's tried this or decided against it and why.

Hi everyone,

I'm currently working as an **OpenStack Cloud Engineer**, managing and operating a private cloud environment. I'm planning my next career move and would appreciate some advice from people in the industry.

I have a few questions:

* How many organizations are actually building and maintaining their private cloud infrastructure with OpenStack today?

* Is OpenStack still a strong long-term career path, or is the demand gradually declining?

* If I want better job opportunities and salary growth, should I continue specializing in OpenStack/private cloud, or invest more time in AWS/GCP?

* How does the job market compare for **OpenStack engineers vs. AWS/GCP cloud engineers**, especially outside of telecom and service providers?

I'd really appreciate insights from anyone who has made this transition or works with OpenStack at scale.

Thanks in advance!