1. 11 Oct, 2016 1 commit
  2. 12 Sep, 2016 1 commit
    • David Johnson's avatar
      Parallelize image/quota/network/user setup. · 1f589f23
      David Johnson authored
      openstack commands take way too long, and these are parallelizable.
      Also, let setup-basic.sh always run the IMAGEUPLOADCMDFILE;
      setup-images.sh never tries anymore; it just outputs the file.  Good
  3. 09 Sep, 2016 1 commit
    • David Johnson's avatar
      Refactor VM image setup; support extra images; add user import script. · 3b3a8d50
      David Johnson authored
      This cleanly refactors everything we do to VM images (asserting the
      random passwd, disabling root passwd, changing sshd config, etc).  This
      allows us to support adding extra images based on URL/name user provides
      us in params, and to allow them to call our script after profile
      instantiation to add an image.  It's fairly comprehensive and it
      certainly works for the common cloud images from various linux vendors.
      It also rolls multi-nic support into each image.  We do this via
      boot-time udev scripts and dhcp hooks that ensure we don't add routes
      for interfaces other than eth0 (this ensures that the default gateway is
      always attached to eth0).  The old, hacky, sometimes-broken multi-nic
      support is gone, as is the special image.  I have no idea why cloud
      images don't just include this feature by default... it's not hard at
      We support Ubuntu and Fedora/Centos.  We support basically the image
      formats that qemu-nbd supports (i.e., qcow, vmware, vdi, raw), and gz or
      xz compression.  That seems to cover the core spectrum.
      On aarch64, we yank the kernel and initrd out of the image's /boot and
      create an AMI/AKI/ARI image tuple, instead of uploading the raw disk
      image.  I have never figured out how to boot a raw Ubuntu cloud image on
      KVM/aarch64, and the HP guys never got back to me.  So this is the only
      way I know (well, there's UEFI, and there's a UEFI aarch64 BIOS, so the
      UEFI cloud images might work... but life is way too short for all that
  4. 19 Aug, 2016 1 commit
    • David Johnson's avatar
      Add Mitaka; unified controller/networkmanager; Manila; linuxbridge. · 6d23a989
      David Johnson authored
      The feature notes:
        * Mitaka is now the default OpenStack release configured by this
          profile.  Kilo and Juno are deprecated, and we are no longer testing
          the profile's functionality under those versions (although we have
          no concrete plans to remove the code at this point).  They may
          continue to work, or they may not.  You should update to Mitaka if
          possible, of course.
        * The default topology is now down to 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`.
        * One of the bigger Mitaka features is shared filesystem support
          (Manila).  We download a shared filesystem image and configure
          Manila so that you can immediately create a share and connect it to
        * We have added support for the Neutron ML2 "Linuxbridge" driver,
          although we continue to install the "OpenVSwitch" ML2 driver by
          default.  The Linuxbridge driver is not as well-tested as the
          OpenVSwitch driver, in all possible configurations of this profile.
          Although OpenStack has switched to the linuxbridge driver as its
          default, we have no plans to do that yet.
        * You can now choose an Apt mirror and set a custom mirror path if you
          require fast localized access to a mirror.
        * The MTU that dnsmasq pushes to your OpenStack VMs 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
          on a normal physical network with 1500-byte MTU.  Somehow this
          mistake escaped prior testing.
      A few details:
        * I refactored the Neutron ML2 plugin setup code, since all nodes
          have to be configured essentially the same way.  Moreover, it
          supports either openvswitch or linuxbridge.
        * I haven't setup Manila for aarch64 because there is no available
          Manila service image for aarch64.  Have to build one of my own.
  5. 25 Feb, 2016 1 commit
  6. 17 Feb, 2016 1 commit
  7. 01 Feb, 2016 1 commit
    • David Johnson's avatar
      Use a less lame swapper == geniuser check. · 8a8fa109
      David Johnson authored
      If you instantiate a portal expt on Emulab (where you might have a real
      account), the swapper is you, not geniuser.  So, check geniuser via
      geni-get slice_urn success/failure.
  8. 03 Sep, 2015 1 commit
  9. 30 Jul, 2015 2 commits
    • David Johnson's avatar
    • David Johnson's avatar
      Make sure openstack special IPs don't stomp on our flat lan phys IPs. · c2676e3a
      David Johnson authored
      For our flat lan case, we run lans directly over the top of real (or
      emulab vlan) networks.  So we extend those emulab IP networks into
      the openstack flat network associated with each emulab network.  Well,
      openstack assumes it controls the subnet and can just allocate special
      addresses anywhere -- like for the local dhcp agent IP, or a router
      interface -- it doesn't respect the allocation_pool value we give the
      network (so that must just be for compute nodes).
      Further, there's no way to set these special IPs when creating networks,
      subnets, and routers, so we retroactively find those ports and change
      their IP addrs to something that won't stomp on emulab IPs, nor on the
      openstack allocation_pool.
      This seems to work great, except that packets outbound from an openstack
      instance don't get SNAT'd so they appear they came from the real
      external world address.  Inbound packets make it all the way, so at
      least DNAT is working.
  10. 28 Jul, 2015 1 commit
  11. 16 Jul, 2015 1 commit
    • David Johnson's avatar
      Lots of new features, especially drastically improved network config. · a9265ea7
      David Johnson authored
      Setup several kinds of networks: tunnels, flat networks, flat networks
      multiplexed via vlans over physical networks (where openstack doesn't
      manage the vlan ids), and real vlan networks (where openstack *does*
      manage the vlan ids).  Tunnels always go over the first flat data net.
      Be very flexible in terms of assigning IPs; generate them ourselves
      if they dind't come to us, or if user wants to use our generated ones.
      I tried to be smart (enough) with this.
      Setup VNC-based consoles on x86-64; working in dashboard.
      Don't put plaintext admin password in profile anymore; instead, expect
      a hash of the admin password.  Replace the temp admin password in the
      keystone database with the hash we get.  But, since the CLI tools
      all require real user auth, setup a secondary 'adminapi' account
      that is a real admin, and use that to see admin-openrc.sh for CLI
      tools, and for all our configuration, and places where the services
      use a real admin account to auth.  Also, push the admin password
      hash all the way into our instance images.
  12. 22 Apr, 2015 1 commit
  13. 18 Apr, 2015 1 commit
  14. 20 Mar, 2015 1 commit
  15. 18 Mar, 2015 1 commit
    • David Johnson's avatar
      Tweak the network setup config so it's right. · 0c32c3b0
      David Johnson authored
      And also, don't add extra network public gateways via
      ext-net if there aren't enough public IPs.  We need at
      least 2 so that there is 1 floater and 1 for the private-to-public
      router interface :(
  16. 17 Mar, 2015 1 commit
  17. 13 Mar, 2015 5 commits