simplify early-boot-config dependencies

[bcressey]

Issue number:
N/A

Description of changes:
Take advantage of the new metadata provides to simplify the early-boot-config dependencies.

Testing done:
Build log for aws-dev:

#15 0.807  bottlerocket-early-boot-config         x86_64   0.0-0             repo   919 k
#15 0.807  bottlerocket-early-boot-config-aws     x86_64   0.0-0             repo   5.1 M
#15 0.807  bottlerocket-early-boot-config-local   x86_64   0.0-0             repo   2.4 M

Build log for metal-dev:

#15 0.920  bottlerocket-early-boot-config         x86_64   0.0-0             repo   919 k
#15 0.920  bottlerocket-early-boot-config-local   x86_64   0.0-0             repo   2.4 M
#15 0.920  bottlerocket-early-boot-config-metal   x86_64   0.0-0             repo   6.3 k

Build log for vmware-dev:

#15 0.823  bottlerocket-early-boot-config          x86_64   0.0-0            repo   919 k
#15 0.823  bottlerocket-early-boot-config-local    x86_64   0.0-0            repo   2.4 M
#15 0.823  bottlerocket-early-boot-config-vmware   x86_64   0.0-0            repo   1.7 M

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.

[sam-berning]

Changes look correct to me. My only concern is that it's adding back in some variant-aware conditional compilation to packages/, but this does seem like the logical end of the packaging setup we landed on with early-boot-config-${PLATFORM}.

Just reasoning through this for my own sake, in full-OOTB world it seems like we'll want the early-boot-config package to just install the binary and data-providers.d directory (and maybe the local file providers?). And then OOTBuilders should package in any data providers they want to use themselves. Does that sound right to you @bcressey ?

[bcressey]

My only concern is that it's adding back in some variant-aware conditional compilation to packages/, but this does seem like the logical end of the packaging setup we landed on with early-boot-config-${PLATFORM}.

It's admittedly variant-aware, but the appeal of this approach is that the RPMs are actually not conditionally compiled: they are always built the same way, but with a boolean dependency that only triggers if a condition is met at install time. We do still have the one bottlerocket-metadata RPM that is conditionally compiled when building the variant, which is what ultimately drives the different install behaviors we want.

In concrete terms, if you inspect the package you can see that all the requirements are present on the same artifact:

❯ rpm -qp --requires build/rpms/bottlerocket-early-boot-config-0.0-0.x86_64.rpm
(bottlerocket-early-boot-config-aws if bottlerocket-variant-platform(aws))
(bottlerocket-early-boot-config-metal if bottlerocket-variant-platform(metal))
(bottlerocket-early-boot-config-vmware if bottlerocket-variant-platform(vmware))
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1
rpmlib(RichDependencies) <= 4.12.0-1

Just reasoning through this for my own sake, in full-OOTB world it seems like we'll want the early-boot-config package to just install the binary and data-providers.d directory (and maybe the local file providers?). And then OOTBuilders should package in any data providers they want to use themselves.

Yes, although the behavior change from PR is that if they name their OOTB variant "aws-*" then it will now automatically pull in early-boot-config-aws. I feel like this is almost always going to be desirable. If it turns out not to be, we would need to shift the binary and directories to a subpackage (e.g. early-boot-config-core) that could be installed separately from any provider.

The OOTBuilder would also need to avoid installing the release package, since that will now pull in early-boot-config and give them the matching provider. However, they will likely need to do that regardless for anything that's deeply customized: release covers a lot of ground, and is quite a bit more opinionated than just the "in EC2, we want to support reading user data from IMDS" opinion that this encodes.

[sam-berning]

Got it, thanks for the explanation!

Yes, although the behavior change from PR is that if they name their OOTB variant "aws-*" then it will now automatically pull in early-boot-config-aws. I feel like this is almost always going to be desirable.

Yeah agreed, I think this is really nice, although it feels a bit "magic". We should probably make a note somewhere in a future OOTB guide that the variant name does matter (i.e. it changes behavior) in some ways.