vmware-variants: migrate host-container versions to latest versions

[etungsten]

Issue number:
N/A

Description of changes:

Author: Erikson Tung <etung@amazon.com>
Date:   Tue Jan 11 13:32:12 2022 -0800

    vmware-variants: migrate host-container versions to latest versions
    
    We haven't been migrating host-container versions for vmware-variants.
    This migration migrates all previous host-container versions to the
    latest host-container version on upgrade.
    
    It is unclear what version of the host-containers we should downgrade to
    since it could be any of the older host-container versions.
    We can just stay on the latest host-container version since there are no
    breaking changes.

Testing done:
Built v1.6.0 with migration and uploaded to my own TUF update repository.
Then I built a v1.2.0 vmware-k8s-1.20 OVA and launched a VM with it.
Before updating to v1.6.0:

[ec2-user@198 ~]$ apiclient -u /settings?keys=settings.host-containers.admin.source
{"host-containers":{"admin":{"source":"public.ecr.aws/bottlerocket/bottlerocket-admin:v0.7.2"}}}
[ec2-user@198 ~]$ apiclient -u /settings?keys=settings.host-containers.control.source
{"host-containers":{"control":{"source":"public.ecr.aws/bottlerocket/bottlerocket-control:v0.5.1"}}}

After updating to v1.6.0, the migration ran and the host-container sources got updated as expected:

bash-5.0# updog check-update 
vmware-k8s-1.20 1.6.0
bash-5.0# updog update -r -n
Starting update to 1.6.0
...
bash-5.0# cat /etc/os-release 
NAME=Bottlerocket
ID=bottlerocket
VERSION="1.6.0 (vmware-k8s-1.20)"
PRETTY_NAME="Bottlerocket OS 1.6.0 (vmware-k8s-1.20)"
VARIANT_ID=vmware-k8s-1.20
VERSION_ID=1.6.0
BUILD_ID=082e231c-dirty
HOME_URL="/~https://github.com/bottlerocket-os/bottlerocket"
SUPPORT_URL="/~https://github.com/bottlerocket-os/bottlerocket/discussions"
BUG_REPORT_URL="/~https://github.com/bottlerocket-os/bottlerocket/issues"
bash-5.0# apiclient -u /settings?keys=settings.host-containers.admin.source
{"host-containers":{"admin":{"source":"public.ecr.aws/bottlerocket/bottlerocket-admin:v0.7.3"}}}
bash-5.0# apiclient -u /settings?keys=settings.host-containers.control.source
{"host-containers":{"control":{"source":"public.ecr.aws/bottlerocket/bottlerocket-control:v0.5.4"}}}

After rolling back, the host-containers version stayed on the latest as expected,

bash-5.0# signpost rollback-to-inactive
bash-5.0# reboot
....
bash-5.0# apiclient -u /settings?keys=settings.host-containers.admin.source
{"host-containers":{"admin":{"source":"public.ecr.aws/bottlerocket/bottlerocket-admin:v0.7.3"}}}
bash-5.0# apiclient -u /settings?keys=settings.host-containers.control.source
{"host-containers":{"control":{"source":"public.ecr.aws/bottlerocket/bottlerocket-control:v0.5.4"}}}

I tried the same procedure with a v1.3.0 vmware-k8s-1.21 OVA and produced the same results.

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[etungsten]

I want to open this up for discussion.
The alternative to this is to create separate migrations between all the older versions of bottlerocket with incremental host-container version bumps instead of just having a single migration that bumps all versions to latest. This is feasible with how we push updates and how migrations work. But I'm not sure what reasons we may have for doing that.

[etungsten]

One reason might be for the 'enter-admin-container' script introduced in control-container v0.5.4. Since the script depends on apicliet exec which is a feature introduced in Bottlerocket version 1.4.0. The script wouldn't work on hosts older than v1.4.0.

[zmrow]

My vote: I think the bump from the existing version to the latest is fine. On downgrade, I would expect my host containers to go back to the version they were before the upgrade. If there is a specific reason for someone to use one of the incremental versions, that version could be supplied via setting.

[etungsten]

On downgrade, I would expect my host containers to go back to the version they were before the upgrade.

Unfortunately we can't definitively know what the previously-set host-container source is once we've migrated since it could be any of the older versions we migrated from. The only way to preserve that information is to have a chain of migrations, i.e. a migration between each Bottlerocket host version where we bumped the default host-container versions.

[webern]

have a chain of migrations

This is probably the right thing to do.

[jpculp]

Hm. I have mixed feelings about this. I think in the instance that folks are downgrading and want a specific version, they should set it via user-data. The version of the container they had before would be dependent on the version when the host was initially set up, not necessarily the version they are rolling back to.

[zmrow]

🦅