Tuesday, August 18, 2015

New and Improved OpenStack Profile

We've developed a new and improved OpenStack profile.  It has evolved from the Tutorial-OpenStack profile referred to in the CloudLab manual, but uses newer CloudLab features (geni-lib scripts, profile parameters, and multi-site ability), and exposes many more OpenStack configuration options.  Our OpenStack profiles all use stock Ubuntu OpenStack packages insofar as possible to minimize experiment instantiation time.  Here's a brief summary of the new features; more details follow below.

  • Use profile parameters to easily change the number of compute and network resources in your experiment, or control its OpenStack configuration
  • Choose Kilo on Ubuntu 15, or Juno on Ubuntu 14
  • Add computes nodes at a second CloudLab cluster, using CloudLab's beta support for multi-site experiments
  • Try different Neutron network configurations (flat, GRE-tunneled, vxlan, or vlan-based networks)
  • Use CloudLab's support for creating multiple experiment network links atop a single physical device
  • Better control the management network (choose VPN over public CloudLab control net, or over experiment net (possibly shared atop a single physical NIC with other networks in your experiment))
  • Configure several OpenStack features (remote serial console access, security groups, etc)
  • Use "bare" Ubuntu CloudLab images on your physical nodes (or your own custom images), without OpenStack packages preinstalled, or use images with most necessary software preinstalled (the default) to speed up experiment creation
First, the profile is no longer just a large RSpec description of the experiment; it is now based on a geni-lib script (read the CloudLab documentation on geni-lib for more detail).  geni-lib scripts are Python scripts that output an RSpec description of your experiment.  Using geni-lib classes, you programmatically describe the resources you want in your experiment and configure them---i.e., add nodes, create LANs and links between them, and install software or scripts on them.  When this geni-lib-based python script is run, it will print out an RSpec that describes your experiment.

Second, the profile's geni-lib script makes liberal use of CloudLab's profile parameters.  Parameters can be set by the user of the profile when creating an experiment, and different values can cause the geni-lib script to produce a new, different RSpec.  Of course, each parameter has a default value, so if you don't change any defaults, your experiment will be created using the RSpec generated by running the script with no input parameter values.

If you look at the profile's source (not the RSpec, but the geni-lib source), you'll see a Python script.  It may seem complicated, but much of the complexity is caused by its multiplicity of parameters!  It's commented, so you can look through it, but its basic flow is to 1) define input parameters, default values, and help docs; 2) process any input parameter values and generate errors and warnings as needed; 3) set a description and instructions that are shown to the user at experiment creation; 4) create objects describing experiment resources (nodes, LANs, public IP addresses, etc); 5) add a special "parameter" geni-lib resource, to send several parameter values to the scripts we install on the nodes to change their behavior; and finally, 6) print the RSpec!

When you create an experiment using this profile, after your nodes have booted, each node runs a shell script that enables secure, peerwise root ssh, so that the root user, on any node in your experiment, can ssh to any other node.  The network manager node ("nm" by default) then connects to each node and 1) configures the management network, and 2) sets up an openvswitch configuration by placing the correct physical network devices into openvswitch bridges.  (Since some CloudLab clusters have nodes that provide up to 5 experiment network interfaces, the physical ethernet devices in these bridges may change, even if you create a second experiment with the same parameter values---but the shell scripts that set up OpenStack deal with all this for you.)  Finally, the shell script running on the network manager ("nm") node connects to the controller ("ctl") node, and begins setting up all the OpenStack services, which itself involves additional configuration for the network manager and for each compute node.

Due to the extra OpenVSwitch-based configuration these scripts perform, over and above the default CloudLab configuration that is applied to each experiment, you cannot currently snapshot experiments based on this profile --- if you do, and create a new experiment based on your snapshot, your experiment networks will almost certainly be misconfigured.  If there's a lot of interest in this, we may work to make it possible.

Much of the configuration in these shell scripts comes from the OpenStack instructions for Apt-based Linux distributions, and we hope that makes this profile easy to modify if you need.  Just download the tarball referenced in the profile's geni-lib source code, unpack it, and modify the scripts as you'd like; then create a new profile that uses your tarball instead of the default.  Or, if you'd like to propose a new feature or configuration, you can ask on cloudlab-users@googlegroups.com --- we can't promise to accommodate your request, but we might try.  Please do report bugs to that mailing list, and we'll do our best to fix them.