Add boot steps configuration option

[jacob-carlborg]

Adds a new configuration option called boot_steps. This is an array of tuples of boot commands, to type when the virtual machine is booted. The first element of the tuple is the actual boot command. The second element of the tuple, which is optional, is a description of what the boot command does. This is intended to be used for interactive installers that requires many commands to complete the installation.

Both the command and the description will be printed when logging is enabled. When debug mode is enabled Packer will pause after typing each boot command. This will make it easier to follow along the installation process and make sure the Packer and the installer are in sync.

This is the SDK part of hashicorp/packer-plugin-qemu#103.

[jacob-carlborg]

@lbajolet-hashicorp ping

[lbajolet-hashicorp]

Hi @jacob-carlborg, sorry for letting this linger for so long, I was working on other stuff.

Regarding your PR I think it sets the stage for what we may want, but I think if we want this to become more generally usable, we need to make a change to the GenerateExpressionSequence function, and the expression implementations more generally, so they can choose which boot sequence to use and get it working.

This may not be a trivial change, and I'm not completely aware of what it entails yet, we should probably investigate on that so we can support the code you're proposing. As I mentioned in the Qemu repo, I like the idea of adding some context to a series of commands, rather than just mindlessly typing the boot commands sequentially over whatever driver we want to use.

At the same time, this will likely change the interface for the plugins, so I'm not sure what to do with it.

Ping @nywilken, what do you think? I think this is a valuable feature, but we should probably have a discussion and setup a plan for this to work as seamlessly as possible. Though if we go the interface-changes route, this will trigger some necessary updates when bumping the SDK to a newer version.

In the meantime @jacob-carlborg, since you implemented this on Qemu first, and you have an issue opened on the repo for this, we can probably merge a Qemu-specific implementation for this, and then think about what we want to do in order to make it more broadly available.
Once the SDK supports the general implementation, if it ever does, we can then merge it in Qemu.
Apologies for pointing you to opening a PR on the SDK, it was premature on my part as this will have consequences on the broader plugin ecosystem, we need to ponder first what and how to do it.

We can keep this PR opened, and we can come back to it later.

[jacob-carlborg]

@lbajolet-hashicorp No worries. I'll update the QEMU PR.

[nywilken]

@lbajolet-hashicorp thanks for the ping, and @jacob-carlborg thank you for pushing this forward on the QEMU builder. I agree that this would be a nice addition to the SDK for supporting descriptive boot commands. Alternatively we can think about the usage of template_files to see how we can promote a workflow where boot commands can external to a template for reusability.

This is not something we can prioritize at the moment so I will close this PR. But I reopened the original issue as #216 in the SDK and marked at as a proposal for us to revisit when we are done with the bundled plugins and SDK 0.6.0 releases.