Jmt/ootb/pluto

[jmt-lab]

Issue number: #3620

Closes #3620

Description of changes:

Removes conditional compilation from pluto.

• Changes pluto to fetch the necessary settings it needs via apiclient get cli
• Removes pluto from use as setting-generator calls
• Introduces pluto systemd unit to run to generate its settings after sundog and before settings-applier
• Uses apiclient set to set its generated settings
• New migration helper RemoveMetadata introduced along with unittests

Testing done:

• Ran cargo +nightly udeps to ensure all unused dependencies have been removed
• Pass the settings on first boot via userdata. Verify config.
• cat /etc/os-release record your build ID include commit sha, record this
• Downgrade to older version.
  • verify connectivity
  • cat /etc/os-release to verify lower version
  • verify that migrations have changed the metadata/settings as expected (i.e. they are gone from the datastore, or lists have been changed back)
• Upgrade to newer version.
  • verify connectivity
  • cat /etc/os-release to verify version

Tested with downgrade -> upgrade

Initial Build ID 1.20.0 0bb2977
Downgrade Build ID 1.19.5 64049ba
Upgrade Build ID 1.20.0 0bb2977

Verified that pluto in both situations generated correct settings
Verified that the new remove metadata does a noop on downgrade and setting-generators return
Verified that the new remove metadata removes setting-generator settings on upgrade

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.

[jmt-lab]

Fix formatting

[jmt-lab]

Rebased, build fixes, tests ran

[webern]

You need a clippy fix

[jmt-lab]

• Rebased on latest
• Removed redundant build.rs
• Undid debug change
• Removed unnecessary variable

[bcressey]

Migrates pluto out of os package to its own package

Why? Generally speaking the whimsical names shouldn't intrude into the visible surface area of the distro. For OOTBs that will also include package names.

Historical aside: pluto is so-named because it's a settings generator, and the program that invokes settings generators is called sundog, because it's the counterpart to early-boot-config, which used to be called moondog, which is the source of non-generated settings. moondog was one of the earliest names, back when the desert code name was "Atacama" instead of "Thar"; the Atacama Desert has the Very Large Telescope and hence there was an astronomical theme early on, before Thar let us unlock the pirate pun naming achievement. Bottlerocket was started in part by Amazon Linux veterans and observed the Amazon Linux tradition of using deserts as code names for major releases.

Back on topic: I am more OK with the generic ones like updog (for updates) and netdog (for networks) but would still prefer that they stay in the os aggregate package or else move to the appropriate settings-* package once those get rolling. For netdog in particular, splitting it out makes sense because there's a lot going on there and a separation of concerns is useful.

Aside from not wanting to export whimsy or to explain pluto ever again, I'm concerned about compile times exploding if we start compiling serde a hundred times in parallel.

[jmt-lab]

Migrates pluto out of os package to its own package

Why? Generally speaking the whimsical names shouldn't intrude into the visible surface area of the distro. For OOTBs that will also include package names.

Historical aside: pluto is so-named because it's a settings generator, and the program that invokes settings generators is called sundog, because it's the counterpart to early-boot-config, which used to be called moondog, which is the source of non-generated settings. moondog was one of the earliest names, back when the desert code name was "Atacama" instead of "Thar"; the Atacama Desert has the Very Large Telescope and hence there was an astronomical theme early on, before Thar let us unlock the pirate pun naming achievement. Bottlerocket was started in part by Amazon Linux veterans and observed the Amazon Linux tradition of using deserts as code names for major releases.

Back on topic: I am more OK with the generic ones like updog (for updates) and netdog (for networks) but would still prefer that they stay in the os aggregate package or else move to the appropriate settings-* package once those get rolling. For netdog in particular, splitting it out makes sense because there's a lot going on there and a separation of concerns is useful.

Aside from not wanting to export whimsy or to explain pluto ever again, I'm concerned about compile times exploding if we start compiling serde a hundred times in parallel.

I was just following netdog since we pulled it out when doing a similar conditional removement, I'm okay sliding this back into os.spec if that is preferred

Review was on old approach

[jmt-lab]

Updated to ensure the compilation changes with pluto & cfsignal work well. Note I will be addressing shibaken and other remaining if blocks in another PR

[jmt-lab]

• Fixed unwrap in get_max_pods
• Remove build_variant

[webern]

Is the empty file packages/os/pluto-toml intentional? If so can you explain why you need an empty file?

[jmt-lab]

Removed unnecessary test

[jmt-lab]

Interactive rebase done to better arrange changes

[jmt-lab]

Rebased to squash commits and separate migration
Rebased off latest develop

[webern]

• The Pluto code looks correct to me, to the best of my ability with the caveat that I can't quite tell if there could be a subtle behavior change based on the fact that Pluto used to be called at different times for these things and may have had different settings available when that occurred.
• The migration seems probably correct, though I have a question about "nothing to do on downgrade".
• I mostly deferring to Ben on packaging concerns.

[webern]

Double-checking this is right, @bcressey. We don't need to do anything on downgrade because the defaults will cause the metadata to be put back into place on downgrade, right?

[bcressey]

Double-checking this is right, @bcressey. We don't need to do anything on downgrade because the defaults will cause the metadata to be put back into place on downgrade, right?

Yes. migrator.service runs before storewolf.service and (simplifying) is responsible for fixing things up so the datastore that storewolf deserializes matches what the model expects.

storewolf will add any new defaults to an existing data store (since 036be78) but does not touch existing data.

One conclusion I've drawn from this - frankly downright weird! - migration is that there's probably something much smarter we could do for the datastore files that cannot be set via the API, such as "remove all existing metadata so that storewolf puts it back".

But that would fall outside the scope of what we can cover in any one set of up/down migrations; we'd need the OS itself to be smart enough to do that, which means doing the repo pivot trick to move to the new world where we can treat it as a given.

If we did that, we could expand the scope to include configuration-files and services too. Might as well throw in unrecognized prefixes and individual files while we're at it, and the ability to set a field to {{ default }} to force it to be re-evaluated to its current default value. Potentially we could eliminate almost all of what we use migrations for even in the current settings system.

[jmt-lab]

• Rebased on latest
• Refactored to use generate methods that pass aws_k8s_info
• Triggered node_ip off cluster_dns
• Retested everything functioned as expected

[bcressey]

🪐