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. 28 May, 2019 1 commit
  2. 24 May, 2019 1 commit
  3. 13 May, 2019 1 commit
  4. 10 May, 2019 1 commit
  5. 09 May, 2019 1 commit
  6. 06 May, 2019 1 commit
  7. 17 Apr, 2019 1 commit
  8. 09 Feb, 2019 1 commit
  9. 08 Feb, 2019 1 commit
  10. 18 Oct, 2018 3 commits
  11. 13 Jul, 2018 4 commits
  12. 03 Jul, 2018 1 commit
  13. 22 Jun, 2018 1 commit
  14. 25 May, 2018 1 commit
  15. 29 Jan, 2018 2 commits
  16. 02 Jan, 2018 3 commits
  17. 29 Nov, 2017 1 commit
  18. 27 Nov, 2017 1 commit
  19. 23 Oct, 2017 1 commit
  20. 13 Jan, 2017 1 commit
  21. 11 Oct, 2016 1 commit
  22. 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.
  23. 04 May, 2016 1 commit
  24. 19 Feb, 2016 1 commit
    • David Johnson's avatar
      On Liberty aarch64, enable vnc using vga driver disabling usb input. · fde6f527
      David Johnson authored
      Liberty didn't seem to like the disable_vnc flag to Nova on aarch64 that
      we relied on so that images would boot.  Fortuitously, qemu/libvirt have
      been upgraded enough so that you can actually attach a VGA adapter to an
      aarch64 KVM qemu instance.  So we do that, and now we mark images with a
      specific flag that says to use the vga display driver instead of the
      'cirrus' default, which qemu/libvirt aarch64 does *not* support.
      Probably I should just find a way to fix the vnc disablement :).
  25. 17 Feb, 2016 1 commit
    • David Johnson's avatar
      Patch oslo.service to avoid nasty hangs on service stop. · ea548968
      David Johnson authored
      Apparently oslo.service handles stop signals (like those from systemd)
      in a bad way.  When systemd stops a service, it can drive the service
      into an exception (in one of its threads, I think) and I assume systemd
      waits until its timeout and then kills it more firmly.  This patch went
      in to oslo.service 1.2.0 or so, but of course we're stuck back in the
      stone age still, around 0.9 or whatever.  So apply the patch, stupid.
      We start and stop services a lot as we're setting up.
  26. 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.
  27. 02 Dec, 2015 1 commit
    • David Johnson's avatar
      Make package installation optional, and separate install/upgrade. · b2634d01
      David Johnson authored
      Quit trying to apt-get packages if they're installed, unless the
      user selects the new DO_APT_UPGRADE option.  Always install was nice
      in the beginning, but it is no longer the best use case, and it can
      cause uncertainty when failures happen (i.e., if new versions of
      packages get installed that the scripts can't handle).  So now there
      are three apt options in the scripts and in the geni-lib script:
      DO_APT_UPDATE -- updates the apt cache (often hard to do pkg
        install/upgrade if the cache is out of date); defaults to 1
      DO_APT_INSTALL -- if this is set 0, we don't install *anything*
        other than critical deps (think python-m2crypto); defaults to 1
      DO_APT_UPGRADE -- if this is set 1, we always run apt-get install
        to either install and/or upgrade OpenStack packages and deps.
        The big change is that this now defaults to 0 -- so packages are
        not upgraded from their current versions if they exist.
  28. 24 Nov, 2015 1 commit
  29. 21 Oct, 2015 1 commit
  30. 16 Sep, 2015 1 commit
  31. 31 Jul, 2015 1 commit
    • David Johnson's avatar
      Serial console support. · f905c8e7
      David Johnson authored
      Openstack doesn't yet have 1) serial console client builtin to
      dashboard, nor 2) serial console log + r/w serial console access.
      So right now, you have to choose if you want to enable r/w console
      access via CLI client, or if you want to be able to view serial logs in
      the dashboard web UI; default is the latter (logs).
      If you enable r/w consoles, we download a simple websocket console
      client, setup a little frontend script, so users can type
        $ /root/setup/ <instancename>
      and get to the console.  Escape is ~.  In addition to the console CLI
      tool, we have to grab the latest version of the python websocket
      library, cause the one in Ubuntu 15.04 is horribly out of date and
      doesn't seem to support binary/base64 websockets, which the console CLI
      tool requires (as does the server).
  32. 30 Jul, 2015 1 commit
    • David Johnson's avatar
      Use the right vnc proxy URL for multi-site. · 37dc2bfa
      David Johnson authored
      Right now, the vnc proxy sits on the controller only.
      I suppose eventually we could try to run a proxy on each
      machine directly, if that's possible... but for now keep
      it simple (and high-latency ;)).