balena-os / takeover

Migrate arbitrary devices to balena
12 stars 8 forks source link

Refactor connection migration #72

Closed lmbarros closed 6 months ago

lmbarros commented 6 months ago

This PR is just refactoring the code in order to make it simpler to understand and maintain in the long run. There shall be no functional changes here.

There are two commits with small changes (fixing typos, and using constant), and two other commits with more substantial changes to system connections migrations:

  1. Keep the code better aligned with previously existing code that did similar things.
  2. Factor the code comparing the two system connection locations to a separate function.

Testing: I ran three migration scenarios manually, all working fine:

  1. NUC to Generic amd64. (And here I did some variations to try the cases in which we detect discrepancies between the two locations with system connections.)
  2. From 64-bit Devuan to 64-bit balenaOS on a Pi 3.
  3. From 32-bit Raspberry Pi OS to 64-bit balenaOS on a Pi 3.

For convenience, here's a copy of the commit messages for the two larger commits.


We have recently added code to migrate system connection and proxy configs during balenaOS-to-balenaOS migrations. That code was working correctly, but it wasn't following the same patterns as similar previously existing code followed.

This commit refactors the new code to follow the established patterns, which shall make takeover maintenance easier.

Being more specific, the idea is to make the new code more aligned with the code we already had for handling WiFi networks:

  1. In migrate_info.rs populate the MigrateInfo fields. This is what we were already doing for wifis.
  2. In stage1.rs do the actual copying. Again, this is similar to what we did for `wifis``: this is the same place we currently already create the connection files for WiFi.

In summary, this is just trying to keep similar operations closer together in the code, which hopefully will help future maintainers to understand it.


This commit just factors out the comparison of system connection locations into a separate function. This keeps the main migration code path cleaner and easier to follow.