Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate to core kit #4060

Merged
merged 12 commits into from
Jun 20, 2024

Conversation

arnaldo2792
Copy link
Contributor

Issue number:

Related to #4048

Description of changes:

This PR migrates the code to use the Bottlerocket core kit.

Testing done:

  • Built an AMI with my personal core kit, and verified the host booted.

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.

They are now provided by the Bottlerocket Core Kit

Signed-off-by: Arnaldo Garcia Rincon <[email protected]>
@arnaldo2792 arnaldo2792 force-pushed the migrate-to-core-kit branch 5 times, most recently from 16b2606 to c23d72f Compare June 17, 2024 20:09
Copy link
Contributor

@cbgbt cbgbt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! 🚀

This looks good to me so far, I'll take another look when the tests are passing.

@arnaldo2792 arnaldo2792 force-pushed the migrate-to-core-kit branch 2 times, most recently from f6d6e51 to 7a7b5dd Compare June 17, 2024 22:55
"api/thar-be-updates",
"api/settings-committer",
"api/migration/migrator",
"api/apiclient",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this is out of alphabetical order with datastore

"updater/signpost",
"updater/update_metadata",
"updater/updog",

"constants",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

duplicate?

@@ -39,3 39,4 @@ path = "../variants.rs"
[build-dependencies]
settings-defaults = { path = "../../packages/settings-defaults" }
settings-plugins = { path = "../../packages/settings-plugins" }
settings-migrations = { path = "../../packages/settings-migrations" }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: out of alphabetical order

@bcressey
Copy link
Contributor

Looks good to me once we have the first core kit release.

arnaldo2792 and others added 6 commits June 18, 2024 18:10
They were migrated to the Bottlerocket Core Kit

Signed-off-by: Arnaldo Garcia Rincon <[email protected]>
…dencies

All the packages the variants depend on are already built in the
Bottlerocket Core Kit

Signed-off-by: Arnaldo Garcia Rincon <[email protected]>
Signed-off-by: Arnaldo Garcia Rincon <[email protected]>
It was migrated to the Bottlerocket core kit

Signed-off-by: Arnaldo Garcia Rincon <[email protected]>
Migrations need to stay in-tree along with plugins and defaults,
because they are directly related to how settings are configured and
how they evolve from one release to the next.

Signed-off-by: Ben Cressey <[email protected]>
arnaldo2792 and others added 4 commits June 19, 2024 23:43
Signed-off-by: Arnaldo Garcia Rincon <[email protected]>
The SDK is built for two host architectures - x86_64 and aarch64.
Each build includes the same two target architectures. However, the
libstd.so binary for a given target architecture will not be the same
across the two host SDK images, because they are built on different
systems and at different times.

To reduce file sizes, we prefer dynamically linking to libstd for all
Rust binaries, and arrange to install libstd through the libstd-rust
package. Prior to the kit migration, we always built the final image
with the same host SDK image that was used to build all packages, so
the question of which libstd should be shipped never came up.

In the kits world, we need the libstd-rust that corresponds to the
many Rust binaries that come from the core kit. However, if we prefer
dynamic linking, then we also need the libstd-rust that matches the
Rust binaries built locally, which may not be the same if the kit was
built on a different host architecture.

Sidestep this for now by not preferring shared linking for settings
plugins, so that they are statically linked to the libstd present in
the build environment, and do not require it to be installed in the
final image.

Signed-off-by: Ben Cressey <[email protected]>
Signed-off-by: Arnaldo Garcia Rincon <[email protected]>
Copy link
Contributor

@cbgbt cbgbt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

@arnaldo2792 arnaldo2792 merged commit f36b20a into bottlerocket-os:develop Jun 20, 2024
31 checks passed
@bcressey bcressey mentioned this pull request Jun 20, 2024
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants