1. 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
          guests.
      
        * 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.
      6d23a989
  2. 16 Feb, 2016 1 commit
    • David Johnson's avatar
      Add Liberty support and configurable Keystone API version support. · 0dd7c424
      David Johnson authored
      Add Liberty support.
      
      Add keystone v3 support.  Now you can choose which version of keystone
      to run... all combinations tested exception Juno with v3.
      
      Make node type and link speed configurable.
      
      Make token and session timeouts much longer by default (so people don't
      get logged out so quickly), but also configurable.
      
      Keystone is now served by WSGI through Apache on Kilo and Liberty.
      
      Memcached keystone token caching is disabled for now; it causes
      intermittent problems; so using SQL for now.
      
      Add localhost to /etc/hosts file.  This doesn't cause problems anymore,
      if it ever did.
      
      We now use the `openstack' CLI command for >= Kilo, instead of the
      per-service client CLI tools.
      
      Stick with ovs agent even in Liberty -- even though the default is now
      linuxbridge, it seems.
      
      In general, get rid of nearly all the rest of the cat <<EOF ... EOF
      stuff and replace it with crudini --set/--del.  A touch slower, but much
      cleaner.
      
      Also in general, improve the Kilo support so that it more closely
      matches the docs.
      0dd7c424
  3. 06 Oct, 2015 1 commit
    • David Johnson's avatar
      A nasty hack to get pubkeys into Openstack "portably". · 6def427b
      David Johnson authored
      This is really, really ugly.  So, keystone and nova don't offer us a way to
      upload keypairs on behalf of another user.  Recall, we're using the adminapi
      account to do all this setup, because we don't know the admin password.  So,
      the below code adds all the keys as 'adminapi', then we dump the sql, do some
      sed magic on it to get rid of the primary key and change the user_id to the
      real admin user_id, then we insert those rows, then we cleanup the lint.  By
      doing it this way, we eliminate our dependency on the SQL format and column
      names and semantics.  We make two assumptions: 1) that there is only one field
      that has integer values, and 2) the only field that is an exception to #1 is
      called 'deleted' and we just set those all to 0 after we jack the whacked sql
      in.  Ugh, it's worse than I hoped, but whatever.
      
      This is one of the sickest one-liners I've ever come up with, but it
      works like a charm!
      6def427b
  4. 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.
      a9265ea7
  5. 18 Apr, 2015 1 commit
  6. 22 Mar, 2015 1 commit
  7. 20 Mar, 2015 1 commit