We currently hardcode the assumption of the system partition size in our installer code. The picked value there is future-proof, for Metropolis, but not flexible enough to support other payloads.
Another payload we actually install is TestOS, which is happy with O(megabytes) for a system partition size. Having a hint for TestOS that is lower than the hardcoded Metropolis size would let us allocate less data for system partition in tests.
Notably, this would unblock testing a full takeover flow, which currently only goes up to the Agent running, because installing TestOS is impossible on the Debian cloud image we test against - the hardcoded partition size is just too big to fit there.
Our bundle format does not yet have any metadata within itself (it's just a Zip file), so this is also an opportunity to rework this - either shove some proto into the bundle zip, or change the bundle format entirely.
We currently hardcode the assumption of the system partition size in our installer code. The picked value there is future-proof, for Metropolis, but not flexible enough to support other payloads.
Another payload we actually install is TestOS, which is happy with O(megabytes) for a system partition size. Having a hint for TestOS that is lower than the hardcoded Metropolis size would let us allocate less data for system partition in tests.
Notably, this would unblock testing a full takeover flow, which currently only goes up to the Agent running, because installing TestOS is impossible on the Debian cloud image we test against - the hardcoded partition size is just too big to fit there.
Our bundle format does not yet have any metadata within itself (it's just a Zip file), so this is also an opportunity to rework this - either shove some proto into the bundle zip, or change the bundle format entirely.