1. 02 Mar, 2018 2 commits
  2. 22 Feb, 2018 1 commit
  3. 21 Feb, 2018 4 commits
  4. 20 Feb, 2018 1 commit
  5. 12 Feb, 2018 1 commit
  6. 03 Feb, 2018 1 commit
  7. 30 Jan, 2018 2 commits
  8. 25 Jan, 2018 1 commit
  9. 12 Jan, 2018 1 commit
  10. 09 Jan, 2018 1 commit
    • Mike Hibler's avatar
      Yet another layer of backward compat... · afa1569d
      Mike Hibler authored
      If we support provenance but not deltas, then we do not use the
      newer create-versioned-image when creating images from Xen vnodes.
      However, we had a bug in that path where we would then not pass the
      imageid argument to the old script, resulting in us spewing the image
      out to stdout which got put in the logfile.
      afa1569d
  11. 01 Jan, 2018 1 commit
  12. 23 Dec, 2017 1 commit
  13. 14 Dec, 2017 1 commit
  14. 06 Dec, 2017 1 commit
  15. 27 Nov, 2017 1 commit
  16. 21 Nov, 2017 2 commits
  17. 20 Nov, 2017 1 commit
  18. 19 Nov, 2017 6 commits
  19. 17 Nov, 2017 2 commits
  20. 09 Nov, 2017 1 commit
    • Mike Hibler's avatar
      Introduce a "failed" state for resource allocation. · 7e13f79b
      Mike Hibler authored
      If a background resource allocation fails, we put the lease in the "failed"
      state instead of destroying it. There were some ripple effects, specifically,
      the lease_daemon now checks for "failed" leases and send messages to us at
      the same frequency as for "unapproved" leases. The correct response here is
      almost certainly to destroy the lease, though you can put it back in the
      "unapproved" state (via modlease) and try to approve it to see what happened.
      
      Also add background mode to approvelease since it can do time consuming
      resource allocation.
      
      Nit: cleanup logfiles used in backgroud operation.
      7e13f79b
  21. 07 Nov, 2017 1 commit
    • Mike Hibler's avatar
      Changes to the way lease (dataset) creation works: · 65b1e100
      Mike Hibler authored
       * A failure to allocate resources results in the embryonic dataset being
         destroyed. Previously, we would just leave it "unapproved". This means
         that, for a background lease creation, either the lease will eventually
         wind up in the "valid" state (success) or it will disappear (failure).
      
       * If creation fails early due to a policy violation, we exit with the
         value 2. Other early (non-background) exits will be 1 or -1 (255).
         This allows the a calling script to easily differentiate policy
         violations (for which the user might want to appeal via -U) from other
         more serious failures.
      65b1e100
  22. 03 Nov, 2017 2 commits
  23. 23 Oct, 2017 1 commit
  24. 20 Oct, 2017 1 commit
  25. 13 Oct, 2017 1 commit
  26. 10 Oct, 2017 1 commit
  27. 27 Sep, 2017 1 commit