All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

  1. 25 Jul, 2019 1 commit
  2. 23 Jul, 2019 1 commit
  3. 16 May, 2019 1 commit
  4. 09 May, 2019 2 commits
  5. 25 May, 2018 1 commit
  6. 15 Dec, 2017 1 commit
  7. 25 Oct, 2017 1 commit
    • David Johnson's avatar
      Fix new "requirement" triggered by neutron-ovs-cleanup. · e03b4467
      David Johnson authored
      Some services assume they can resolve the hostname prior to network
      being up (i.e. neutron-ovs-cleanup).  neutron-ovs-cleanup in particular
      seems to not allow the ovs bridges to forward until it finishes.  This
      is very bad.  So, to workaround, put the real control net ip and FQDN
      into /etc/hosts too, both statically at setup (so it is there for the
      first reboot), and in the rc.hostnames hook (so it is there after future
  8. 13 Jan, 2017 1 commit
  9. 11 Oct, 2016 2 commits
    • David Johnson's avatar
      Improvements in ovs/linuxbridge iface config and hosts file setup. · 938d5fe0
      David Johnson authored
      Also, I had to change the linuxbridge configuration around.  I'd been
      using statically-configured linux bridges, and I'd assumed I could tell
      Neutron to use them.  Unfortunately, this is sort of true, but not
      enough; from the comments:
       NB: We can only control the name of the external br-ex bridge,
       because only the Neutron linuxbridge driver accepts both a map of
       physical networks to physical interfaces; and physical network to
       bridge names.  Nova assumes that the bridge it must plug a device
       into is named according to the physical network uuid.  Thus, for
       the linuxbridge case, we only setup bridge_mappings for
       br-ex... modulo a flag.  Hopefully in the future they will see the
       sense in allowing static bridge configurations.
      So for now, only br-ex is static; the others are dynamic.  What a pain
      for debugging!  Stupid.
      More importantly, this commit also takes integrates correctly with the
      new Emulab clientside improvements that let the user customize interface
      config and /etc/hosts file generation.  To handle hosts, we create a
      static manifest file that tells Emulab to call an rc.hostnames
      pre-hook.  This hook basically grabs our latest special openstack hosts
      entries, and ensures they make it into /etc/hosts.head, so that
      genhostsfile prepends our special names.  To handle interfaces, we
      further customize /etc/network/interfaces so that Emulab's rc.ifconfig
      only tries to configure interfaces we haven't handled.
      Thus, if the clientside of the disk image the scripts are operating on
      includes the new clientside hookable support, we no longer move
      rc.ifconfig and rc.hostnames out of our way --- we let them run, secure
      in the knowledge that our customizations won't get trampled.
      (All this improvement was necessary so that blockstores and event system
      stuff would work.)
    • David Johnson's avatar
  10. 12 Sep, 2016 1 commit
  11. 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.
  12. 13 Jul, 2016 1 commit
    • David Johnson's avatar
      First step in Mitaka support: support ctl-only openstacks (2 nodes). · 8167c83f
      David Johnson authored
      The docs have been recommending a unified networkmanager-ctl physical
      node now since Liberty, instead of the old 3-node approach.  Obviously
      this has appeal for us, so get this done before doing any
      Mitaka-specific stuff.
      It really wasn't as hard as I thought... basically just worked with
      these few changes.  We no longer assign an 'nm' name at all.
      (Also, this commit has my dev tarball in instead of the real
      thing, because there is no real thing yet.)
  13. 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
      Also in general, improve the Kilo support so that it more closely
      matches the docs.
  14. 14 Oct, 2015 1 commit
  15. 28 Jul, 2015 1 commit
  16. 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 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.
  17. 18 Apr, 2015 1 commit
  18. 17 Mar, 2015 1 commit
  19. 13 Mar, 2015 1 commit
    • David Johnson's avatar
      Scripts to install and configure Openstack on Ubuntu. · 4f72a60c
      David Johnson authored
      These are a collection of scripts that install and configuration
      Openstack Juno on Ubuntu 14 and onwards, within an Emulab/Apt/Cloudlab
      testbed experiment.
      (The included dh2048.pem is a time-saving optimization enabling faster
      experiment swapins; it's optional.)