1. 10 Feb, 2017 5 commits
  2. 09 Feb, 2017 13 commits
  3. 08 Feb, 2017 4 commits
  4. 07 Feb, 2017 5 commits
  5. 06 Feb, 2017 2 commits
  6. 04 Feb, 2017 2 commits
  7. 03 Feb, 2017 4 commits
    • David Johnson's avatar
      Fix route saving in Linux firewall code to preserve default route. · 044c33bd
      David Johnson authored
      Our firewall rules rely on the ability to resolve names.  Thus, the
      manipulation we do on the firewall node to move the control net from a
      NIC to a bridge with the NIC inside it must save all the routes, too.
      
      If this code used to do that properly for Ubuntu 10, it certainly does
      not for Ubuntu 16, for one of potentially multiple reasons.  So I wrote
      some fun code to do its very best to save all routes related to the
      control net device (including the default route) in such a way as to 1)
      obtain *all* routes before tearing *any* down any; and 2) to ensure that
      the transformed routes can be safely restored.  (This will then work for
      any testbed with an obtuse control net setup in which the default route
      is insufficient to reach boss, not that that will ever happen.)  This
      code does its thing on both the enable/disable paths, of course.  Here's
      the relevant details from the code:
      
          This is very, very messy.  We have to save the
          existing routes for $pdev, but in an order that they
          can be restored without failing, before we move
          $pdev into br0.  Then the restored routes must be
          rewritten in terms of br0 instead of $pdev.
      
          Finally, we have to collect these routes prior to 1)
          assigning $pdev's IP to br0, and 2) moving $pdev
          into br0, and 3) prior to *deleting* any routes.
          All these conditions seem necessary to me.
      
          ip route show does not necessarily display routes in
          restoreable order.  In particular, the thing that
          bites is that the default route is (now, as of
          Ubuntu16, at least) displayed *prior to* the scope
          link (broadcast route) for a device).  So, we first
          harvest the scope link routes for $pdev (i.e., the
          natural ones that come into being as a side affect
          of assiging an IP address to a link); then we
          harvest all other routes associated with $pdev; then
          we remove all routes associated with $pdev.  Then we
          do the mucking about with bridge membership and
          transfer IP from $pdev to bridge, and finally,
          restore the routes we saved (modified to br0, of
          course).
      044c33bd
    • Leigh Stoller's avatar
      Tweaks to previous revision. · c4c24d16
      Leigh Stoller authored
      c4c24d16
    • Leigh Stoller's avatar
    • Leigh Stoller's avatar
      Update for modern images. · 50841a48
      Leigh Stoller authored
      50841a48
  8. 02 Feb, 2017 3 commits
  9. 01 Feb, 2017 2 commits
    • Leigh Stoller's avatar
      Remove debugging code. · 4fb328bd
      Leigh Stoller authored
      4fb328bd
    • Leigh Stoller's avatar
      Checkpoint the portal side of frisbee events. · 2faf5fd1
      Leigh Stoller authored
      The igevent_daemon now also forwards frisbee events for slices to the
      Portal pubsubd over the SSL channel.
      
      The aptevent_daemon gets those and adds them to sliverstatus stored in
      the webtask for the instance.
      
      The timeout code in create_instance watches for frisbee events and uses
      that as another indicator of progress (or lack of). The hope is that we
      fail sooner or avoid failing too soon (say cause of a giant image backed
      dataset).
      
      As an added bonus, the status page will display frisbee progress (image
      name and MB written) in the node status hover popver. I mention this
      cause otherwise I would go to my grave without anyone ever noticing and
      giving me pat on the back or a smiley face in Slack.
      2faf5fd1