OpenStack Profile "Liberty" Support

We've done another round of updates the OpenStack profile and the images it's based on, and wanted to share the important changes -- and encourage you to migrate to this latest version insofar as possible.  Here's a quick summary:

• Liberty support (Kilo and Juno still available, but upgrade if you can)
• Keystone v3 API enabled by default for both Kilo and Liberty (but can select v2.0 if preferred)
• Migrate (for Kilo and greater) to the "openstack" CLI client for configuration, instead of the per-service CLI clients
• Parameters for choosing node type and link bandwidth
• Increase token and horizon (dashboard) timeouts to let web users remain logged in longer (these are parameters with long default values)
• Migrate (for Kilo and greater) to Keystone via WSGI/Apache (but this is also a parameter, so you can select the old method of the Keystone Python API server)

We've traditionally configured OpenStack in accordance with the installation documentation, using their defaults when possible.  However, this time, there are some notable changes:

• Keystone doesn't use Memcache by default (although it's an option)
• We continue to use the openvswitch Neutron driver to manage networks; the Liberty docs have switched to the linuxbridge driver
• We continue to use a split controller/networkmanager installation, unlike the docs, which now unite the controller and networkmanager.  We'll probably migrate to this eventually.
• We set the default resource limits to unlimited for Nova, Neutron, and Cinder (the default resource limits can be left intact by unchecking the quotas parameter)

Thanks for reading, and please report any problems to cloudlab-users@googlegroups.com .  If you're not a member, please join!

Glibc Vulnerability Patching

Hi all,

In order to apply patches for the recent glibc resolver buffer
overflow vulnerability, we plan to reboot all of the CloudLab control
servers today at 5PM MST. This will temporarily interrupt
instantiation of new experiments, and the CloudLab web portal will
also be unavailable for 15 minutes or so.

Related to this glibc vulnerability, we ask that you:

* Please perform a software update on nodes in running experiments

If you expect that your experiment(s) will run for more than two days
from now, please update your nodes via the running OS's distribution's
update mechanism:

As root on Ubuntu:

apt-get update
apt-get upgrade
reboot

As root on CentOS:

yum update
reboot

Notes: If "grub" is updated in this process, it may ask where it
should install itself.  Choose "/dev/sda1" for anything other than
Ubuntu 12.  For Ubuntu 12, choose "/dev/sda2".  Also choose to keep
any existing configuration files if/when prompted (e.g., for Grub,
OpenSSH server, etc.)

* Please update your custom disk images

If you use a custom disk image, please perform a system software
update as described above, and re-snapshot your image.

Email support@cloudlab.us with questions.

More info on the glibc vulnerability can be found here:

https://access.redhat.com/articles/2161461

OpenStack Profile and Image Changes and Updates

We've updated both the OpenStack profile and the images it's based on, and wanted to point out some important changes -- and encourage you to migrate to this latest version insofar as possible.

First, we've changed the way OpenStack packages are installed and/or upgraded by the scripts.  Originally, for several reasons, we wrote the profile's setup scripts to always install the latest version of the OpenStack packages.  That no longer makes sense, because 1) the Ubuntu OpenStack packages are pretty stable right now; and 2) we can (and now do) provide a profile parameter that allows you to upgrade to the latest packages if you like.  However, by not updating the pre-installed packages by default, we can significantly reduce the load the scripts put on the Ubuntu package mirrors -- and more importantly, provide a more stable profile that isn't a moving target.  This more reasonable default is long overdue; thanks for waiting for it.  There are now three options that affect package installation on the nodes in your OpenStack experiments.  The first is new; the latter two were previously present.

• Upgrade OpenStack packages and dependencies to the latest versions
  If a package is already installed, we don't try to upgrade it to the latest version unless this option is selected.  The default is false (unselected).
• Install required OpenStack packages and dependencies
  If this option is false (unselected), the setup scripts assume all required OpenStack packages are installed, and it only installs critical dependencies that it absolutely requires for its own execution.  By default, of course, this option is true (selected).  If the "Upgrade" option detailed above is false, and OpenStack packages are already installed, nothing will happen.  If packages are not pre-installed, if this option is selected, they will be installed.
• Update the Apt package cache before installing any packages
  This option gives you control over whether or not the scripts update the Apt package cache before doing any package installation/upgrades.  Typically, it's a bad idea to not update the cache, as you may end up trying to install packages that are no longer present on the mirrors; but this gives you that choice just in case.

Second, we've updated the Cloudlab software installed on the images the profile uses, to pull in some important updates.  When you pick Kilo as your OpenStack version, the Ubuntu 15 images your experiment will use now support swap partitions on x86 (most Cloudlab images have a swap partition in the standard partition layout, of course, but the right systemd helper services were not installed on Ubuntu 15).  The ARM-specific images (usable only at Cloudlab Utah, our ARM-based cluster) use our more modern partition layout, so instead of a whole-disk root partition, there is space for you to create partitions.  In particular, the setup scripts create a secondary partition as a backing store for an LVM physical volume.  The ARM-specific images now also have an important Cloudlab software update that allows the system boot initramfses to be properly regenerated (important if the kernel is upgraded, or if the installation of some package triggers the automatic rebuild of the initramfs).  Finally, all images have the most recent Ubuntu package versions of OpenStack Kilo and Juno pre-installed (unless you select the option to start "from scratch", which deliberately uses images that don't have the packages pre-installed).

Third, we've improved the profile's documentation a little bit.  When you swap in an experiment, you'll see a markdown rendering instead of the giant glob of text.  Hopefully this will make things more clear -- although we didn't attempt to document everything.

Finally, we've disabled non-current versions of this profile, meaning that you cannot instantiate nor copy those profile versions.  Please instantiate using the latest version.

Thanks for reading, and please report any problems to cloudlab-users@googlegroups.com (if you're not a member, you should join!).

Changes to the default OpenStack profile

We have three announcements to make today regarding the default OpenStack profile in CloudLab:

1. The OpenStack profile now randomly generates a new password for every experiment. This password is used for the 'admin' login in the OpenStack web interface and for password ssh logins to VMs created by OpenStack. The password for your experiment can be found in the "Instructions" panel in the experiment status page. 

   

   OpenStack profile instructions showing admin/root password

2. It's now easier to tell when OpenStack is done setting up. The Topology view of the experiment status now has little icons on each node showing the status of the scripts that set up that node. Now, when OpenStack setup is complete, all of these icons will change to checkmarks, and the 'State' of the experiment will change from "booted" to "ready". It's normal for the control node to take much longer to finish setting up than the compute or network manager nodes; it has a lot more work to do.



Profile topology view showing three ready nodes

3. We are deprecating the "Tutorial-OpenStack" profile in favor of the "OpenStack" profile. The "OpenStack" profile covers all features offered by the tutorial version, and more. We are not deleting the Tutorial-OpenStack profile at this time, but it is no longer selected by default, and we do not encourage people to use it for new experiments.

Important Tutorial-OpenStack and OpenStack Profile Change

For security reasons, we have changed the CloudLab-provided OpenStack profiles to modify the way root login is handled on the VMs brought up by OpenStack.  This also affects most other OpenStack profiles on CloudLab (those that use our OpenStack setup scripts). Note that this change does not affect CloudLab profiles that do not use OpenStack.

Password login is no longer allowed for the "root" account. If you need to log in directly to your VMs as root, you will need to use an ssh keypair. Password login is still allowed for the 'ubuntu' account, so if you do not have a keypair set up, you may use that account instead.

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.

New Feature: Console Logs

Many users have requested that they be able to access the console logs, back to the beginning of their experiment. This can be handy, since the console shell may not have what you are looking for if it happened sometime in the past.

On the status page, there is a new context menu item:

When you click on "Console Log" a new window (or tab) is created, and after a few seconds the console log is inserted into the new window. The delay might be as long as five seconds, take a sip of coffee while you wait.

Note that the log does not update in real time, nor can you refresh the window because of how the access security is handled. You need to go back to the topology and the context menu to request a new download. If this becomes a problem, please let us know and we will see if we can do something about it.