Skip to content
  • Leigh B Stoller's avatar
    Big set of changes for deferred/scheduled/offline aggregates: · 6f17de73
    Leigh B 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.
    6f17de73