commit cd9d3eef5209c1367b06019102beef2818cc8c20
Author: Greg Althaus <galthaus@austin.rr.com>
Date:   Sat May 23 13:00:13 2020 -0500

    build: fix unit tests to be more stable.

M   backend/profiles_test.go
M   go.mod
M   go.sum

commit 51e707c6d22270aa375709ae8518afd76e2eec50
Author: Victor Lowther <victor.lowther@gmail.com>
Date:   Thu May 21 17:35:01 2020 -0500

    fix(startup): Delete invalid WAL files that do not have data

    If dr-provision was shut down while it was trying to create a new WAL
    segment but was unable to do so due to a disk full condition, the
    system can be left in a state where manual intervention is required to
    come back up even after the disk space issue has been resolved.  This
    patch recognizes a few of those invalid WAL segment conditions and
    just deletes the invalid WAL segment instead of erroring out.

M   clitest/bootenv_test.go
M   datastack/stack.go
M   datastack/streamingSyncPassive.go
M   datastack/wal.go

commit c10194d0b33dce9b7b34714f78e6aff5ba073bf6
Author: Victor Lowther <victor.lowther@gmail.com>
Date:   Wed May 20 16:53:22 2020 -0500

    fix(ipxe): Bump ipxe version to 1.20.1

    We haven't built ipxe from scratch for a couple of years.  Bump it to
    get crunchy new hardware and bugfixes.

M   embedded/assets/ipxe-arm64.efi
M   embedded/assets/ipxe.efi
M   embedded/assets/ipxe.lkrn
M   embedded/assets/ipxe.pxe

commit b70973ee5b35a5f9f798b20396fdb0a4df7e24d1
Author: Victor Lowther <victor.lowther@gmail.com>
Date:   Wed May 20 16:38:42 2020 -0500

    fix(bootloader): Fix crash when bootloaders is not fully populated

    The bootloader chooser code crashed when only a subset of the
    default bootloaders was overridden.  This patch fixes that.

M   backend/bootenv.go

commit e96d3563f5611111c36714636f4917a1da517a03
Author: Greg Althaus <galthaus@austin.rr.com>
Date:   Wed May 20 12:00:22 2020 -0500

    fix(datastack): make sure content pack name is loaded

M   datastack/stack.go

commit 4e8dbcb5925cbeb468068a1e7caffa57b6571857
Author: Victor Lowther <victor.lowther@gmail.com>
Date:   Mon May 18 12:45:21 2020 -0500

    perf(dhcp): Improve DHCP parallelism in packet processing.

    DHCP packet processing has (until this commit) has the ability to
    bottleneck the rest of the system, due to the midlayer DHCP packet
    handling code having no ability to throttle itself and the backend
    DHCP lease handling code being effectively serialized behind a mutex.

    Thsoe two issues in combination with excessively slow WAL flushes and
    a DHCP broadcast storm can combine to cause the DHCP server to
    effectively deadlock everything else and spin up extra goroutines
    until the server runs out of memory.

    This patch fixes both of those issues.

    In the midlayer, we will now only handle one DHCP packet request/reply
    cycle per macaddress at a time.  This will help handle DHCP
    performance during broadcast storms and cases where we are reciving
    multiple incoming packets from the same server due to misconfigured
    relays, switch misconfiguration, or whatever.  Any duplicate packets
    from the same MAC address (as determined by MAC address and DHCP
    message type) are now ignored entirely.  This sets the upper bound of
    goroutines that the DHCP midlayer code can have outstanding to be
    equal to the number of simultaneous DHCP clients trying to exchange
    packets woith it instead of the upper bound being equal to the number
    of packets recieved. Along the way, un-export a few types and methods
    that the outside world does not need to know about.

    In the backend, the DHCP utility functions are serialized based on
    DHCP strategy and token instead of serializing behind a single mutex.

M   backend/dhcpUtils.go
M   backend/dhcpUtils_test.go
M   midlayer/abp.go
M   midlayer/dhcp.go
M   midlayer/dhcpUtil.go
M   midlayer/dhcp_test.go
M   midlayer/fake_midlayer_server_test.go
M   midlayer/onie.go
M   midlayer/pxe.go

commit c02aa1363637d189ab2f31394df1685064470fad
Author: Victor Lowther <victor.lowther@gmail.com>
Date:   Mon May 11 11:34:12 2020 -0500

    feat(machines): Add a HardwareAddr index to Machines.

    Recent events have shown us that relying on the machine Address to be
    populated, sane, and up-to-date is not a winning strategy in the face
    of DHCP servers that are not under out control -- if those DHCP
    servers are oversubscribed, then it is possible for the IP address of
    a system to change any time it is not up and running and under our
    control.  However, we still need to be able to create new Machines,
    and we need a better method of checking whether or not a Machine is
    already present based on a set of known criteria.  Probably the best
    set of known criteria is the set of MAC addresses present on the
    system, but we don't have a good way of querying for nodes based on
    that information.  As a starting point, add an Index to Machines that
    allows us to see what Machines have HardwareAddrs we are interested

    While we are at it, make machine validation use the new Index to make
    sure machines do not have overlapping HardwareAddrs, and stop
    uniqueness checking on Machine.Address if skipIPBasedBooting is true.

M   backend/machines.go
M   clitest/test-data/output/TestCorePieces/machines.indexes/stdout.expect

End of Note