Allow variants to specify extra kernel parameters

[tjkirch]

Issue number:

Fixes #1490

Description of changes:

Allow variants to specify extra kernel parameters
    
For example, this is useful when variants designed to run on different
platforms need different serial console parameters.

buildsys: document new variant metadata keys

Note that the parameters are intentionally added to the start of the command line because this isn't intended as an override; our parameters genuinely have to be there! We should design another feature if there are use cases for overhauling the parameters rather than just adding new ones.

Testing done:

Built aws-dev after adding parameters:

 [package.metadata.build-variant]
+kernel-parameters = [
+   "thar-be-params",
+   "thar-be-more-params",
+]
 included-packages = [

Saw the new parameters in /proc/cmdline:

BOOT_IMAGE=(hd0,gpt2)/vmlinuz thar-be-params thar-be-more-params root=/dev/dm-0 rootwait ...

Host was still healthy, ran containers well, systemd status running, API gets/sets OK, etc.

Build aws-k8s-1.17 without adding any parameters and saw that there was no change to /proc/cmdline:

BOOT_IMAGE=(hd0,gpt2)/vmlinuz root=/dev/dm-0 rootwait ...

Host was similarly healthy, and ran pods OK.

Rendered the new docs OK.

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.

[zmrow]

❤️

Code-wise this looks good and will be super useful in the future! Thanks for adding the options to the docs also.

I'll need to experiment a little to ensure that this will fix #1489 . I believe that if we pass the correct console and forward systemd/journald's output to the console that we should be able to see all the output.

[bcressey]

To actually fix #1489 we'll need to move all the console params into the variant definitions - do you want to make that change here or in a different PR?

[tjkirch]

To actually fix #1489 we'll need to move all the console params into the variant definitions - do you want to make that change here or in a different PR?

This PR is intended to add the capability, not make any functional changes.

Why all the params, though? I think it makes sense to leave sensible defaults, tty0 and ttyS0, so that this isn't required for most variants, and variants using other console devices can add them.

[bcressey]

Why all the params, though? I think it makes sense to leave sensible defaults, tty0 and ttyS0, so that this isn't required for most variants, and variants using other console devices can add them.

I quibble a bit with the "sensible defaults" - correct console parameters are inherently platform specific even in the best case, and the ones we have now are strongly influenced by EC2.

They aren't right for VMWare, Raspberry Pi, and perhaps most others. There are also architecture limits on the total size of the command line, so ideally we wouldn't be including redundant parameters in normal cases.

[zmrow]

Looks good!

[zmrow]

^ and yes - agreeing with @bcressey here on the console parameters. We can do that in a separate PR.