1. 11 Oct, 2018 1 commit
  2. 17 Sep, 2018 1 commit
  3. 08 Aug, 2018 1 commit
    • Leigh Stoller's avatar
      Big set of changes for deferred/scheduled/offline aggregates: · 6f17de73
      Leigh Stoller authored
      * I started out to add just deferred aggregates; those that are offline
        when starting an experiment (and marked in the apt_aggregates table as
        being deferable). When an aggregate is offline, we add an entry to the
        new apt_deferred_aggregates table, and periodically retry to start the
        missing slivers. In order to accomplish this, I split create_instance
        into two scripts, first part to create the instance in the DB, and the
        second (create_slivers) to create slivers for the instance. The daemon
        calls create_slivers for any instances in the deferred table, until
        all deferred aggregates are resolved.
        On the UI side, there are various changes to deal with allowing
        experiments to be partially create. For example used to wait till we
        have all the manifests until showing the topology. Now we show the
        topo on the first manifest, and then add them as they come in. Various
        parts of the UI had to change to deal with missing aggregates, I am
        sure I did not get them all.
      * And then once I had that, I realized that "scheduled" experiments was
        an "easy" addition, its just a degenerate case of deferred. For this I
        added some new slots to the tables to hold the scheduled start time,
        and added a started stamp so we can distinguish between the time it
        was created and the time it was actually started. Lots of data.
        On the UI side, there is a new fourth step on the instantiate page to
        give the user a choice of immediate or scheduled start. I moved the
        experiment duration to this step. I was originally going to add a
        calendar choice for termination, but I did not want to change the
        existing 16 hour max duration policy, yet.
  4. 06 Mar, 2018 2 commits
  5. 01 Mar, 2018 1 commit
  6. 26 Dec, 2017 1 commit
  7. 27 Nov, 2017 1 commit
  8. 30 Oct, 2017 1 commit
  9. 06 Sep, 2017 1 commit
  10. 18 May, 2017 1 commit
  11. 10 May, 2017 1 commit
  12. 04 May, 2017 1 commit
  13. 02 May, 2017 1 commit
    • Leigh Stoller's avatar
      Speed up the instantiate page response time, it was taking forever! · af8cc34f
      Leigh Stoller authored
      1. Okay, 10-15 seconds for me, which is the same as forever.
      2. Do not sort in PHP, sort in javascript, let the client burn those
         cycles instead of poor overworked boss.
      3. Store global lastused/usecount in the apt_profiles table so that we
         do not have to compute it every time for profile.
      4. Compute the user's lastused/usecount for each profile in a single
         query and create local array. Cuts out 100s of queries.
  14. 01 May, 2017 1 commit
  15. 09 Feb, 2017 1 commit
  16. 30 Jan, 2017 1 commit
    • Leigh Stoller's avatar
      Fix up problem reported in issue #190 by Eric. · 42af1a08
      Leigh Stoller authored
      The reason for the duplicate profile happens when you instantiate a
      version of the profile, then terminate. That takes you back to the
      instantiate page with default=uuid-of-profile, and if that is a version
      uuid, we end up with a duplicate cause the list is based on the profile
      This closes issue #190.
  17. 28 Dec, 2016 1 commit
  18. 02 Dec, 2016 2 commits
    • Leigh Stoller's avatar
      Remove order by clause in profile query, this causes mysql to use a · 1c211767
      Leigh Stoller authored
      filesort operation, which is a lot slower. And then we throw away the
      results of the sort anyway!
    • Leigh Stoller's avatar
      A couple of little tweaks to deal with slow login: · b2c05d9c
      Leigh Stoller authored
      1. Change initial query in instantiate.php to ask for just the few
         fields we need. Profiles have rspecs and scripts, and that is a lot
         of data to return, given that the average user has access to 300+
         profiles cause of all the ones marked public.
         But in general, there is a lot going on in instantiate.php, which is
         where most users are redirected to after login, and that causes a lot
         of delay.
      2. The MotherShip uses ZFS_NOEXPORT, so when logging in we have to see
         if we have to run exports_setup. exports_setup can take anywhere from
         5-25 seconds. The login path was forcing this once a day, but in fact
         exports_setup is using a week, so lets change the test to match that.
      3. Show a soothing modal after pressing the login button to keep the
         natives happy.
  19. 30 Nov, 2016 1 commit
  20. 29 Nov, 2016 1 commit
  21. 28 Nov, 2016 3 commits
  22. 17 Nov, 2016 1 commit
  23. 12 Nov, 2016 1 commit
    • Leigh Stoller's avatar
      Bring the cluster monitor "inhouse", rather then depending on the jfed · d7c4230e
      Leigh Stoller authored
      monitoring system.
      New portal_monitor daemon does a GetVersion/ListResources call at each
      of the clusters every five minutes, and updates the new table in the
      DB called apt_aggregate_status. We calculate free/inuse counts for
      physical nodes and a free count for VMs. Failure to contact the
      aggregate for more then 10 minutes sets the aggregate as down, since
      from our perspective if we cannot get to it, the cluster is down.
      Unlike the jfed monitoring system, we are not going to try to
      instantiate a new experiment or ssh into it. Wait and see if that is
      necessary in our context.
      On the instantiate page, generate a json structure for each cluster,
      similar the one described in issue #172 by Keith. This way we can easily
      switch the existing code over to this new system, but fail back to the
      old mechanism if this turn out to be a bust.
      Some other related changes to how we hand cluster into the several web
  24. 03 Nov, 2016 1 commit
  25. 24 Oct, 2016 1 commit
  26. 21 Oct, 2016 1 commit
  27. 20 Oct, 2016 1 commit
  28. 05 Oct, 2016 1 commit
  29. 20 Jul, 2016 1 commit
  30. 16 Jul, 2016 1 commit
  31. 23 May, 2016 1 commit
  32. 19 May, 2016 1 commit
  33. 09 Mar, 2016 1 commit
  34. 24 Feb, 2016 1 commit
  35. 27 Jan, 2016 1 commit
  36. 04 Jan, 2016 1 commit