Skip to content

Instantly share code, notes, and snippets.

@vyaghras

vyaghras/bottlerocket_core_kit_pr_294_testing.md

Created December 9, 2024 19:01
Show Gist options
  • Save vyaghras/cc7391ade3b276b223d1814a8770eea7 to your computer and use it in GitHub Desktop.
Save vyaghras/cc7391ade3b276b223d1814a8770eea7 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
bottlerocket_core_kit_pr_294_testing.md

Version 1 : The Bottlerocket image that does not contain these changes. Version 2: The Bottlerocket image that contain these changes and have the migration for the latest host containers. Version 3: The Bottlerocket image that updates the host container versions, but not have migration.

  • Setting-generator for Control and Admin container(storewolf changes)

  • Setting generator in version 1 is string.

  • Setting generator in version 2 is JSON object, containing command, strength and skip-if-populated

  • Setting generator in version 3 is JSON object, containing command, strength and skip-if-populated

  • strength file

  • No strength file exists in version 1.

  • source.strength file with value "weak"(it is a json form that can be serialized and deserialized, hence double quote matters) when boots version 2 first time

  • In version 2, we should see source.strength file with value "weak" when we do in-place update from version 1 and earlier user is using managed host containers.

  • In version 2, we should see source.strength file with value "strong" when we do in-place update from version 1 and earlier user is not using managed host containers.

  • In version 3, we should see source.strength file with value "weak" when we do in-place update from version 2 and earlier user is using managed host containers.

  • In version 3, we should see source.strength file with value "strong" when we do in-place update from version 2 and earlier user is not using managed host containers.

  • API /tx/list

  • The output should be consistent for all three version as no changes in the API.

  • API /tx and /v2/tx

  • Version 1 should return all the pending settings for /tx. The api call /v2/tx should return error for version 1.

  • Version 2 should return all the pending settings for /tx and all the pending settings and metadata for /v2/tx

  • Version 3 should return all the pending settings for /tx and all the pending settings and metadata for /v2/tx

  • API method: DELETE and endpoint /tx

  • apiclient raw -m DELETE -u /tx All version should behave same for this API, and delete the transaction and all the data and metadata in the pending transaction.

  • API /tx/commit or commit_and_apply(as no changes has been done in apply API)

  • Version 1 should commit setting.

  • Version 2 and 3, should be able to commit setting and metadata (only strength metadata) from pending transaction.

  • Version 2 and 3, should be able to set strength metadata with value weak if current metadata is not strong or the strength file does not exist and setting does not exist.

  • Version 2 and 3, no change should happen in strength metadata if the pending strength and committed strength are same.

  • Version 2 and 3, should override the strength metadata with value strong if the pending strength is strong and current is weak.

  • API /tx/apply

  • Should behave consistently for all three versions.

  • API /settings

  • Run apiclient get settings , apiclient raw -u /settings, apiclient get settings.host-containers.admin, apiclient get settings.motd settings.kernel.lockdown. The output of these should be consistent across versions and should populate the settings from live.

  • API method: PATCH, endpoint: /settings and /settings/keypair

  • Version 1: Put the setting in pending transaction default.

  • Version 2 and 3: apiclient raw -m PATCH -u /settings -d '{"motd": "my own value!"}', no strength file should be created for this.

  • Version 2 and 3: apiclient raw -m PATCH -u /settings?strength=weak -d '{"host-containers": {"admin": {"source": "328549459982.dkr.ecr.us-west-2.amazonaws.com/bottlerocket-admin:v0.11.14"}}}', should create the weak strength file in pending, but on commit no change should be there in strength file.

  • Version 2 and 3: apiclient raw -m PATCH -u /settings?strength=strong -d '{"host-containers": {"admin": {"source": "328549459982.dkr.ecr.us-west-2.amazonaws.com/bottlerocket-admin:v0.11.14"}}}', should create the strong strength file in pending and update the strength file in live on commit.

  • Version 2 and 3: Call again with weak flagapiclient raw -m PATCH -u /settings?strength=weak -d '{"host-containers": {"admin": {"source": "328549459982.dkr.ecr.us-west-2.amazonaws.com/bottlerocket-admin:v0.11.14"}}}', should create the weak strength file in pending and not change the strength file in live after commit. Should a warning message saying operation ignored in logs.

  • Version 2 and 3: apiclient set --json '{"motd": "I am new motd"}', should create the strong strength file in pending and no strength file should be created for this in live.

  • Version 2 and 3: apiclient set --json '{"host-containers": {"admin": {"source": "328549459982.dkr.ecr.us-west-2.amazonaws.com/bottlerocket-admin:v0.11.14"}}}' should create the strong strength file in pending and update the strength file in live on commit.

  • Settings-committer

  • Verify settings committer uses version 2 of /v2/tx for Version 2 and Version 3

  • apiclient get os

  • The output should be consistent for all the versions.

  • Upgrades/ downgrades using aws host containers

  • Forward migration from version 1 to version 2.

  • Backward migration from version 2 to version 1.

  • Forward migration from version 2 to version 3.

  • Backward migration from version 3 to version 2.

  • Forward migration from version 1 to version 3.

  • Backward migration from version 3 to version 1.

  • Upgrades/ downgrades using public host containers

  • Forward migration from version 1 to version 2.

  • Backward migration from version 2 to version 1.

  • Forward migration from version 2 to version 3.

  • Backward migration from version 3 to version 2.

  • Forward migration from version 1 to version 3.

  • Backward migration from version 3 to version 1.

  • Version 1 do not use managed host containers

  • Forward migration from version 1 to version 2.

  • Backward migration from version 2 to version 1.

  • Forward migration from version 2 to version 3.

  • Backward migration from version 3 to version 2.

  • Forward migration from version 1 to version 3.

  • Backward migration from version 3 to version 1.

  • Reboots and we can do inplace updates if a metadata is left in the pending transactions

  • If we set using user-data, that should also change the setting to strong.

  • Race conditions

  • Test race condition as:

# live data
motd = "hey"
motd.strength = "weak"

# pending tx 1
motd = "hello" # <--- this is the value someone wants to set
motd.strength = "weak" # <--- this is just incidental because we copied "live

# pending tx 2
motd = "sup" # <--- this is the value someone wants to set
motd.strength = "strong" # <--- we are upgrading this value to strong

# order
# tx 1, then tx 2 = no error
# tx 2, then tx 1 = warn, trying to go from strong to weak, and not change
  • Test if the admin and control container is set from user-data, the setting should be changed to strong.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment