• Leigh B. Stoller's avatar
    Add ReserveSharedBandwidth() method to handle reserving the bandwidth · 8a5eeb82
    Leigh B. Stoller authored
    desired in the vinterfaces table, in the interface_state table.
    Desired bandwidth that has not been reserved is indicated as a
    negative value in vinterfaces; when we update interface_state we also
    update the negative value in vinterfaces (atomically in the same
    query, I am getting good at that multi table stuff).
    You would think this would be simple eh? Well, just you think again.
    Swap modify (update) has to be considered. When doing a swapmod, the
    old version of vinterfaces is in the backup file, and the new version
    is in the vinterfaces table. But we have to know the old reserved
    bandwidth so we know the proper amount to reserve (in other words,
    release the old reserved bandwidth from the previous table). We waited
    till now to do it, since we do not want to get into a situation where
    we release the BW, assign fails, and then someone else got that BW,
    cause then we are screwed and have to swap out the experiment.
    Unfriendly. So, the update changes happen all at once (tables locked).
    So that's it, right? Only for a babe in the woods that you are.
    We also have to consider rollback when swapmod fails and we want to
    restore the old experiment state. This can happen either before we
    have reserved the new bandwidth, or afterwards. Each is a different
    situation, and the only way to know what has happened is to update the
    backup table file in the first part of update so that later rollback
    knows. Yep, I change the backed up vinterfaces table. Twice in fact,
    the second time after the rollback finishes. Gack.
    Note that rollback can suffer from the problem I was trying to avoid
    in update; losing the reserved bandwidth to someone else and having to
    swap out. Nothing to do about that.
Experiment.pm.in 106 KB