from the horse's mouth:
|
# This job runs the PHD migrate-from-base tests, which test upgrading from the |
|
# current mainline propolis-server to the propolis-server version under test. |
|
# |
|
# PHD always uses the propolis-client from the commit under test, so these tests |
|
# will fail if there is a breaking change to the Propolis API. They'll also fail |
|
# if there's a breaking change to the migration protocol. These changes may be |
|
# expected, in which case this run will fail. However, the "regular" phd-run |
|
# job should always be green before merging new PRs. |
|
# |
|
# This job will be removed once API breaking changes are no longer allowed. |
now, a test migrating from mainline propolis-server to the version under test (and back!) is useful, so unlike the comment remarks, I haven't been particularly interested in removing the test. but a few things have changed that make this test less useful than we'd want here..
first, we've stabilized HTTP API versioning across services. now, adding a new HTTP API version to Propolis implies this test will fail, until the new HTTP API version is landed, which would get master and the build under test speaking the same version again. other tests that the version under test can migrate to and from itself probably still pass in those cases! but by adding a new HTTP API version N, migrating to a propolis that only knows version HTTP API N-1 means the old propolis-server just returns an error and the test fails.
perhaps we should have migrate-from-base skip when we're bumping the HTTP API, and as a matter of policy(?) require that HTTP API plumbing not be changed alongside changes to propolis-standalone/propolis-server themselves? "policy" is a pretty subjective and unsatisfactory bar!
second, a VM can have a more storied life, especially once we start actually doing live migration. a VM first incarnated in a Propolis using the V1 API may live-migrate to a Propolis with a V2 InstanceSpec, which may live-migrate to a Propolis with a V3 instance spec. testing that this can migrate to the version under test is important, and is currently untested.
migrating forward along this path should always work, regardless of API version that the propolis-server under test would use in talking to other Propolises.
from the horse's mouth:
propolis/.github/buildomat/jobs/phd-run-migrate-from-base.sh
Lines 16 to 25 in 96e772a
now, a test migrating from mainline propolis-server to the version under test (and back!) is useful, so unlike the comment remarks, I haven't been particularly interested in removing the test. but a few things have changed that make this test less useful than we'd want here..
first, we've stabilized HTTP API versioning across services. now, adding a new HTTP API version to Propolis implies this test will fail, until the new HTTP API version is landed, which would get
masterand the build under test speaking the same version again. other tests that the version under test can migrate to and from itself probably still pass in those cases! but by adding a new HTTP API version N, migrating to a propolis that only knows version HTTP API N-1 means the oldpropolis-serverjust returns an error and the test fails.perhaps we should have
migrate-from-baseskip when we're bumping the HTTP API, and as a matter of policy(?) require that HTTP API plumbing not be changed alongside changes to propolis-standalone/propolis-server themselves? "policy" is a pretty subjective and unsatisfactory bar!second, a VM can have a more storied life, especially once we start actually doing live migration. a VM first incarnated in a Propolis using the V1 API may live-migrate to a Propolis with a V2 InstanceSpec, which may live-migrate to a Propolis with a V3 instance spec. testing that this can migrate to the version under test is important, and is currently untested.
migrating forward along this path should always work, regardless of API version that the propolis-server under test would use in talking to other Propolises.