OpenStack Profile Updated to Mitaka and Ubuntu 16.04

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.  The current version will remain available for instantiation for a few weeks, but then we will disable it.  Here's a quick summary of the new features:

• Mitaka is now the default OpenStack release configured by this profile.  Kilo and Juno are deprecated.  We are no longer testing the profile's functionality under those versions, and we plan to remove these version options in the next version of the profile.  You should update to Mitaka if possible.
• The default topology now includes only two nodes: a controller ("ctl") node and a compute ("cp-1") node; the networkmanager node's functionality has been moved to the controller, as is the default in the OpenStack Ubuntu/Apt documentation.  You can return to the old three-node configuration by changing the name of the networkmanager node in the Advanced Parameters from "ctl" to "nm".
• We have added support for the Neutron ML2 "linuxbridge" driver, although we continue to configure the "OpenVSwitch" ML2 driver by default.  You can select this option by parameter; although if you do, you must also set the number of GRE tunnels to 0, and you will probably want to set the number of VXLAN tunnels to 1 (the "linuxbridge" driver does not support GRE tunnels).  Although OpenStack has switched to the linuxbridge driver as its default, we have no plans to do that, since OpenVSwitch is quite useful to researchers.
• One of the interesting new Mitaka features is shared filesystem support (the "manila" component).  We download a shared filesystem image and configure Manila so that you can immediately create a share and connect it to guests.
• We have added the ability to specify extra images to be included in your OpenStack.  So if the supplied trusty-server image doesn't provide what you need, you can drag in other cloud images by filling in the "Extra Image URLs" parameter.  For instance, you could specify "https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img https://download.fedoraproject.org/pub/fedora/linux/releases/24/CloudImages/x86_64/images/Fedora-Cloud-Base-24-1.2.x86_64.qcow2" and this would get you the default trusty-server image; the latest Ubuntu Xenial Xerus (16.04) image; and the Fedora 24 Cloud Base image.  You could customize the image names if you wanted, by appending a name after an ":" after each URL (i.e. "https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img:XENIAL-SERVER https://download.fedoraproject.org/pub/fedora/linux/releases/24/CloudImages/x86_64/images/Fedora-Cloud-Base-24-1.2.x86_64.qcow2:FEDORA-BASE").
• You can add more images after boot.  Become root, "cd /root/setup", and run "bin/import-image.sh <URL>[:image-name]".  The image import script supports MBR single-partition images only.  It supports compressed images (gz, xz); and these image formats: qcow (any version, theoretically), vmdk, vhd, and raw disk images.  If you have the option, it is best to stick with qcow.  It supports Ubuntu, Centos, and Fedora cloud images.  The import script forces the random passwd your profile was assigned into /etc/shadow for the root and the ubuntu, centos, or fedora user account (each of those user names is the canonical cloud user id for the respective distribution).  This helps ensure your image won't boot with an unsafe passwd.
• The image import script makes some modifications to automatically support multiple NICs (and thus there is no more "trusty-server-multi-nic" image in the image chooser).  By default, cloud images support only a single NIC.  We have added some scripting in the boot path to automatically DHCP on all Ethernet devices.  If you want to use this feature, you just need to pay attention to which interface you bind a floating IP to, because only one interface is associated with the VM's default route.  The DHCP client gets DNS/route/NTP information for each interface from OpenStack; but this information is discarded for the non-eth0 devices.  This means that the first network you add to your instance when creating it is the interface you must bind your floating IP to, because the default route will be associated with that interface (eth0).
• On x86_64, the image import scheme supports only single-partition images, not referential AMI/AKI/ARI tuple images.  You can't currently specify those.  However, on aarch64, we only create AMI/AKI/ARI tuples.  We take single-partition images and convert them into AMI/AKI/ARI tuples by pulling out vmlinuz and initrd from /boot in the single-partition image.
• In the past, the trusty-server* images on aarch64 were pieced together manually.  We no longer bother with that complexity.  Instead, we download the Ubuntu trusty-server disk1 img, and modify it to support our needs, as described just above (image import for aarch64).  Thus, the aarch64 image may feel slightly different.
• The MTU that dnsmasq pushes to your OpenStack VMs via DHCP as they boot has been reduced from 1454 bytes to 1450 bytes.  1454 is an adequate setting for GRE tunnels, of course, but not for VXLAN networks, which require 1450 bytes on a normal physical network with 1500-byte MTU.  Somehow this mistake escaped prior testing.
• You can now specify an Apt mirror and set a custom mirror path if you require fast localized access to a mirror.

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