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.
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.
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
If deploying swift using a simplified deployment two changes will need to be made for the
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
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.