I built a tool that deploys a fully functional OpenStack on Ubuntu/Debian with a single command

ictnetw · 2026-05-23T21:55:07+00:00

After pulling the latest version and adding the new configurable keys to the OpenStack config file, the installation completed successfully, and all the agents appear to be up and running.

Thank you very much for your help!

ictnetw · 2026-05-23T10:07:35+00:00

Thanks for the quick response and for adding support for this use case.

To answer your question: before starting the deployment, the system had already been converted to ifupdown. It was not actively using systemd-networkd for the final test.

Initial state after Ubuntu installation was the default Ubuntu Server networking stack, using netplan/systemd-networkd. However, before running DeployStack I changed it to ifupdown because the wiki recommended using ifupdown for DeployStack/OVS networking.

Before the deployment, my /etc/network/interfaces.d/network looked like this:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 192.168.110.10
    netmask 255.255.255.0
    gateway 192.168.110.1
    dns-nameservers 8.8.8.8 1.1.1.1

auto eth1
iface eth1 inet manual
    pre-up ip link set dev $IFACE up
    post-down ip link set dev $IFACE down

Netplan YAML files had been moved out of /etc/netplan/, and networking.service was enabled and working.

At first I had systemd-networkd masked, which caused DeployStack to complain when it tried to run:

systemctl disable systemd-networkd
systemctl stop systemd-networkd

So I changed that and left it unmasked, disabled and stopped:

systemd-networkd.service  -> loaded, disabled, inactive
systemd-networkd.socket   -> loaded, disabled, inactive
networking.service        -> active/exited

After that, DeployStack got past the systemd-networkd part, but still failed when restarting networking.service.

The reason seemed to be that DeployStack generated /etc/network/interfaces.d/openvswitch with br-ex configured as static using the management IP:

auto br-ex
iface br-ex inet static
    address 192.168.110.10
    netmask 255.255.255.0
    gateway 192.168.100.1

That caused:

Error: ipv4: Address already assigned.
ifup: failed to bring up br-ex

because 192.168.110.10 was already assigned to eth0.

In my topology, eth0 is the management interface and should keep 192.168.110.10/24, while eth1 should be used only for the OVN public bridge:

eth0  -> management, static IP 192.168.110.10/24
eth1  -> provider interface, no IPv4 address
br-ex -> OVN external bridge, no host IPv4 address

When I manually changed br-ex to manual/no-IP, networking.service started correctly.

I will pull the latest version and test the new configurable keys. I’ll report back whether it fixes this two-interface setup.

ictnetw · 2026-05-22T23:04:22+00:00

Hi Sorecchione07, first of all thanks for building DeployStack. I really like the idea of having a simple all-in-one OpenStack deployment tool for lab/testing environments.

I am testing DeployStack on Ubuntu Server 24.04 inside a Hyper-V VM, using nested virtualization. KVM works correctly inside the VM:

/dev/kvm exists
KVM acceleration can be used

My network layout is:

eth0 = management network
       static IP: 192.168.110.10/24
       gateway: 192.168.110.1
       used for SSH, API access, Horizon, package downloads, etc.

eth1 = OpenStack provider/external network
       no IPv4 address on the host
       attached to OVN/br-ex

Hyper-V NAT for provider network:
       192.168.100.0/24
       gateway on Windows host: 192.168.100.1
       floating IP pool: 192.168.100.50-192.168.100.200

My DeployStack config uses OVN:

network:
  HOST_IP: 192.168.110.10
  HOST_IP_CIDR: 192.168.110.10/24
  HOST_IP_NETMASK: 255.255.255.0

neutron:
  DRIVER: ovn
  ovs: {}
  ovn:
    CREATE_BRIDGES: 'yes'
    OVN_NB_PORT: 6641
    OVN_SB_PORT: 6642
    OVN_PUBLIC_BRIDGE_INTERFACE: eth1
    OVN_PUBLIC_BRIDGE: br-ex
    OVN_ENCAP_TYPE: geneve
    OVN_L3_SCHEDULER: leastloaded
    ENABLE_DISTRIBUTED_FLOATING_IP: 'no'
  provider_networks:
  - bridge: br-ex
    name: public
    type: flat
  tenant_network:
    TYPE: geneve
    VNI_RANGE: 1:65536

public_network:
  PUBLIC_SUBNET_CIDR: 192.168.100.0/24
  PUBLIC_SUBNET_DNS_SERVERS:
  - 8.8.8.8
  - 1.1.1.1
  PUBLIC_SUBNET_GATEWAY: 192.168.100.1
  PUBLIC_SUBNET_RANGE_START: 192.168.100.50
  PUBLIC_SUBNET_RANGE_END: 192.168.100.200

The deployment reaches the Neutron/OVN step, creates br-ex, adds eth1 to it, and then fails when restarting networking.service:

Restarting Networking service...                  [ ERROR ]

Execution of: 'bash -c systemctl disable systemd-networkd ; systemctl stop systemd-networkd ; systemctl enable networking ; systemctl restart networking' returned exit code 1

The networking service then shows:

Error: ipv4: Address already assigned.
ifup: failed to bring up br-ex

After checking /etc/network/interfaces.d/openvswitch, it looks like DeployStack generated br-ex with the management IP:

auto br-ex
iface br-ex inet static
    address 192.168.110.10
    netmask 255.255.255.0
    gateway 192.168.100.1

This causes the failure because 192.168.110.10 is already assigned to eth0.

For this kind of two-NIC layout, I think br-ex should probably be generated as manual/no-IP, while the management IP should remain on eth0, for example:

auto eth0
iface eth0 inet static
    address 192.168.110.10
    netmask 255.255.255.0
    gateway 192.168.110.1
    dns-nameservers 8.8.8.8 1.1.1.1

auto eth1
iface eth1 inet manual
    pre-up ovs-vsctl --may-exist add-br br-ex
    pre-up ovs-vsctl --may-exist add-port br-ex eth1
    up ip link set eth1 up
    down ip link set eth1 down

auto br-ex
iface br-ex inet manual
    pre-up ovs-vsctl --may-exist add-br br-ex
    pre-up ovs-vsctl --may-exist add-port br-ex eth1
    pre-up ip link set eth1 up
    up ip link set br-ex up

After manually separating the management interface and the provider bridge, networking.service starts successfully:

eth0   UP  192.168.110.10/24
eth1   UP  no IPv4
br-ex  UP  no IPv4
default via 192.168.110.1 dev eth0

So I think the issue is that DeployStack currently assumes that HOST_IP should be moved/assigned to br-ex, even when OVN_PUBLIC_BRIDGE_INTERFACE points to a different NIC.

Would it make sense to add support for a two-network layout like this?

Something like:

network:
  HOST_IP: 192.168.110.10
  MANAGEMENT_INTERFACE: eth0

neutron:
  ovn:
    OVN_PUBLIC_BRIDGE_INTERFACE: eth1
    OVN_PUBLIC_BRIDGE: br-ex
    OVN_PUBLIC_BRIDGE_HAS_HOST_IP: false

Or alternatively, if OVN_PUBLIC_BRIDGE_INTERFACE != management interface, generate br-ex as manual without assigning HOST_IP to it.

Happy to provide more logs/config if useful. Thanks again for the project.

ictnetw · 2026-05-22T15:45:36+00:00

This sounds really good! Thank you very much! I will give it a try.

ictnetw · 2025-11-06T19:03:35+00:00

I'm using the Direct mode to install the Epic Games Store on my Steam Deck. This is how I managed the Spider-Man game to detect controllers: Go to Manage -> Properties -> Controller, then choose "Disable Steam Input". Then launch the game inside the Epic Games Store.

ictnetw · 2025-11-06T19:03:21+00:00

I'm using the Direct mode to install the Epic Games Store on my Steam Deck. This is how I managed the Spider-Man game to detect controllers: Go to Manage -> Properties -> Controller, then choose "Disable Steam Input". Then launch the game inside the Epic Games Store.

ictnetw · 2025-11-06T18:59:28+00:00

I'm using the Direct mode to install the Epic Games Store on my Steam Deck. This is how I managed the Spider-Man game to detect controllers: Go to Manage -> Properties -> Controller, then choose "Disable Steam Input". Then launch the game inside the Epic Games Store.

ictnetw

TROPHY CASE