Minimal OpenStack-Ansible deployment

Minimal OpenStack-Ansible deployment

Deploying OpenStack-Ansible, and following the deployer documentation, will result in a production-ready OpenStack Cloud. A typical deployment requires operators to setup various network interfaces, use different VLAN tags, and create several purpose-built bridges. But what if these typical requirements couldn't be met or what if the goal was to simply setup an OpenStack cloud using OpenStack-Ansible on a single network device, with a single bridge in a much-simplified environment? This post will answer those questions and provide examples of how to setup a simplified deployment without breaking the ability to upgrade, extend, or reconfigure the cloud later in its lifecycle.

The key to a simplified deployment is within the /etc/openstack_deploy/openstack_user_config.yml. Everything within OSA starts there. It's within this file that we describe the deployment and its the flexibility OSA provides in config that we'll use to create the simplified deployment.

Configuring the Host(s)

The following information augments basic host setup of a typical deployment. From a network perspective, we'll have ONE network device. For the purpose of this post, my ONE network interface will be named eth0 which will be plugged into ONE bridge named br-mgmt.

Here's the network configuration.

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto br-mgmt
iface br-mgmt inet static
    ### flat veth
    pre-up ip link add flat-veth1 type veth peer name flat-veth2 || true  # Create veth pair
    pre-up ip link set flat-veth1 up  # Set the veth UP
    pre-up ip link set flat-veth2 up  # Set the veth UP
    post-down ip link del flat-veth1 || true  # Delete veth pair on DOWN
    ### flat veth
    bridge_stp off
    bridge_waitport 10
    bridge_fd 0
    bridge_ports eth0 flat-veth1
    offload-sg off
    address 172.16.24.53/22
    gateway 172.16.24.2

As you can see in the network interface configuration file, I've got eth0, plugged into br-mgmt with a veth-pair hanging off of it so that I can use flat networking should I ever need or want it.

Flat networking for instances is enabled by plugging one end of a veth pair into the bridge and leaving the other end alone. This results in an interface, flat-veth2, which can be used for instance traffic on a flat network.

With the network interface in place, make any other adjustments needed before moving on to configuring OSA.

Refer to the following article on how the host storage has been setup for container provisioning.

OpenStack-Ansible configuration

To make the simplified deployment process possible the /etc/openstack_deploy/openstack_user_config.yml file will need to be edited so only ONE bridge used for all of the host machines and containers. The following information assumes Openstack-Ansible has been minimally installed.

Using an editor modify the /etc/openstack_deploy/openstack_user_config.yml file tailoring the sections to meet the needs of the deployment. For the minimal deployment example I'll go over each part of the user configuration file that has been modified to make deployments simpler.

Networking

The first thing to do is minimize the cidr_networks. In the simplified deployment, there's only ONE bridge which is also the container bridge. For this reason, the user configuration file will have only the single network CIDR. The used_ips section is still required for any address on the chosen CIDR that should be reserved or is otherwise not available. The global_overrides section is used to define the bridge(s) used for tunnel type networks, management access to containers, and the provider networks that will be setup within neutron and the containers for instance connectivity. Because there's only ONE bridge the provider_networks section is relatively simple. Everything is set to the br-mgmt interface and the network type is defined as the default provider network. Two examples have been provided for both VLAN and FLAT network types.

VLAN Provider Networks
---
cidr_networks:
  container: "172.16.26.0/24"

used_ips:
  - "172.16.26.1,172.16.26.2"

global_overrides:
  internal_lb_vip_address: "172.16.26.1"
  external_lb_vip_address: "172.16.26.2"
  tunnel_bridge: "br-mgmt"
  management_bridge: "br-mgmt"
  provider_networks:
    - network:
        container_bridge: "br-mgmt"
        container_type: "veth"
        container_interface: "eth1"
        ip_from_q: "container"
        type: "vlan"
        net_name: "vlan"
        range: "10:10"
        group_binds:
          - all_containers
          - hosts
        is_container_address: true
        is_ssh_address: true
FLAT Provider Networks
---
cidr_networks:
  container: "172.16.26.0/24"

used_ips:
  - "172.16.26.1,172.16.26.2"

global_overrides:
  internal_lb_vip_address: "172.16.26.1"
  external_lb_vip_address: "172.16.26.2"
  tunnel_bridge: "br-mgmt"
  management_bridge: "br-mgmt"
  provider_networks:
    - network:
        container_bridge: "br-mgmt"
        container_type: "veth"
        container_interface: "eth1"
        ip_from_q: "container"
        host_bind_override: "flat-veth2"
        type: "flat"
        net_name: "flat"
        group_binds:
          - all_containers
          - hosts
        is_container_address: true
        is_ssh_address: true
Swift Deployment

If deploying swift using a simplified deployment two changes will need to be made for the replication_network and storage_network options. Typically these are set to a storage and replication network to isolate the traffic however because the simplified deployment will only have one bridge these settings need to be updated to use the correct network interface. The following example is using the basic swift setup from the OSA example configuration with the two aforementioned changes.

global_overrides:
  swift:
    part_power: 8
    storage_network: 'br-mgmt'
    replication_network: 'br-mgmt'
    drives:
      - name: disk1
      - name: disk2
      - name: disk3
    mount_point: /srv
    storage_policies:
      - policy:
          name: default
          index: 0
          default: True

With the initial configuration resolved for the single network interface and single bridge, refer back to the deployment guide reference for the initial configuration of the OpenStack-Ansible user configuration file.

For a complete example of a simplified deployment (functional and running in a lab) see the following gist.

Running The Deployment

With everything setup within the user configuration files simply run the deployment normally. Everything done within these configuration files is fully supported and will not break the ability to upgrade later.

As the deployment begins building/running containers you'll see only the two network interfaces within the containers; one network tied to lxcbr0 (unmanaged LXC only network) and br-mgmt.

# lxc-ls -f
NAME                                            STATE   AUTOSTART GROUPS            IPV4
compute1_aodh_container-f08d2204                RUNNING 1         onboot, openstack 10.0.3.118, 172.16.26.75
compute1_ceilometer_central_container-56318e0e  RUNNING 1         onboot, openstack 10.0.3.134, 172.16.26.190
compute1_cinder_api_container-86552654          RUNNING 1         onboot, openstack 10.0.3.34, 172.16.26.86
compute1_cinder_scheduler_container-2c0c6061    RUNNING 1         onboot, openstack 10.0.3.66, 172.16.26.153
compute1_galera_container-53877d98              RUNNING 1         onboot, openstack 10.0.3.137, 172.16.26.208
compute1_glance_container-78b73e1a              RUNNING 1         onboot, openstack 10.0.3.199, 172.16.26.241
compute1_gnocchi_container-9a4b182b             RUNNING 1         onboot, openstack 10.0.3.225, 172.16.26.219
compute1_heat_apis_container-c973ef5a           RUNNING 1         onboot, openstack 10.0.3.253, 172.16.26.236
compute1_heat_engine_container-ae51062c         RUNNING 1         onboot, openstack 10.0.3.8, 172.16.26.132
compute1_horizon_container-4148c753             RUNNING 1         onboot, openstack 10.0.3.194, 172.16.26.49
compute1_keystone_container-7a0a3834            RUNNING 1         onboot, openstack 10.0.3.133, 172.16.26.146
compute1_memcached_container-782a6588           RUNNING 1         onboot, openstack 10.0.3.18, 172.16.26.126
compute1_neutron_agents_container-de8a4d37      RUNNING 1         onboot, openstack 10.0.3.150, 172.16.26.220
compute1_neutron_server_container-219f00f7      RUNNING 1         onboot, openstack 10.0.3.87, 172.16.26.57
compute1_nova_api_metadata_container-9a8fe9ae   RUNNING 1         onboot, openstack 10.0.3.101, 172.16.26.170
compute1_nova_api_os_compute_container-2a4faa2c RUNNING 1         onboot, openstack 10.0.3.49, 172.16.26.116
compute1_nova_api_placement_container-42904e4c  RUNNING 1         onboot, openstack 10.0.3.158, 172.16.26.115
compute1_nova_conductor_container-5109b386      RUNNING 1         onboot, openstack 10.0.3.61, 172.16.26.101
compute1_nova_console_container-cf223830        RUNNING 1         onboot, openstack 10.0.3.139, 172.16.26.123
compute1_nova_scheduler_container-832bf438      RUNNING 1         onboot, openstack 10.0.3.92, 172.16.26.199
compute1_rabbit_mq_container-652f0bda           RUNNING 1         onboot, openstack 10.0.3.173, 172.16.26.54
compute1_repo_container-754d214c                RUNNING 1         onboot, openstack 10.0.3.185, 172.16.26.80
compute1_swift_proxy_container-fb47a052         RUNNING 1         onboot, openstack 10.0.3.41, 172.16.26.247
compute1_utility_container-cbd7b73e             RUNNING 1         onboot, openstack 10.0.3.97, 172.16.26.94

We can also see everything from a bridging perspective is also greatly simplified

# brctl show
bridge name     bridge id               STP enabled     interfaces
br-mgmt         8000.0cc47aab5e70       no              219f00f7_eth1
                                                        2a4faa2c_eth1
                                                        2c0c6061_eth1
                                                        4148c753_eth1
                                                        42904e4c_eth1
                                                        5109b386_eth1
                                                        53877d98_eth1
                                                        56318e0e_eth1
                                                        652f0bda_eth1
                                                        754d214c_eth1
                                                        782a6588_eth1
                                                        78b73e1a_eth1
                                                        7a0a3834_eth1
                                                        832bf438_eth1
                                                        86552654_eth1
                                                        9a4b182b_eth1
                                                        9a8fe9ae_eth1
                                                        ae51062c_eth1
                                                        eth0
                                                        c973ef5a_eth1
                                                        cbd7b73e_eth1
                                                        cf223830_eth1
                                                        de8a4d37_eth1
                                                        de8a4d37_eth11
                                                        f08d2204_eth1
                                                        fb47a052_eth1
                                                        flat-veth1

lxcbr0          8000.fe12b24b4ff9       no              219f00f7_eth0
                                                        2a4faa2c_eth0
                                                        2c0c6061_eth0
                                                        4148c753_eth0
                                                        42904e4c_eth0
                                                        5109b386_eth0
                                                        53877d98_eth0
                                                        56318e0e_eth0
                                                        652f0bda_eth0
                                                        754d214c_eth0
                                                        782a6588_eth0
                                                        78b73e1a_eth0
                                                        7a0a3834_eth0
                                                        832bf438_eth0
                                                        86552654_eth0
                                                        9a4b182b_eth0
                                                        9a8fe9ae_eth0
                                                        ae51062c_eth0
                                                        c973ef5a_eth0
                                                        cbd7b73e_eth0
                                                        cf223830_eth0
                                                        de8a4d37_eth0
                                                        f08d2204_eth0
                                                        fb47a052_eth0

Wrap-Up

This post covered some basic setup when running a simplified deployment. I hope this helps answer questions on how something like this might get done and how easy it is to bend OSA to fit the constraints of an environment all without breaking supportability.

Mastodon