switch packaging to use configure-hypervisor.sh script

[jodh-intel]

⚠️ IMPORTANT: This issue should not be actioned until both #34 have landed and the beta has been released.

---

We should switch the packaging scripts to remove all the hard-coded hypervisor options and instead run the script below to generate the correct build options:

• https://github.com/clearcontainers/packaging/blob/master/scripts/configure-hypervisor.sh

[jodh-intel]

Hi @gorozco1 - I also wanted to add @erick0z, but cannot. Does he need to be added as a user to this repo?

[gorozco1]

@jodh-intel yes, he needs to be added to Clear Containers team

[grahamwhaley]

let me see if I can do that...

[grahamwhaley]

Invite should be sent to @erick0z now - @erick0z , you will need to follow a link and accept I believe.

[gorozco1]

@erick0z We need to create an automation script update_qemu.sh

[jodh-intel]

We should look at this again as we currently have 2 copies of the config options in qemu-lite.spec-template and debian.rules-template. Plus, clearcontainers/tests#696.

[erick0z]

@jodh-intel I've recently updated PR #34. I tried to use the configure-hypervisor.sh script but is seems some flags are deprecated. For now, I will build with the flags predefined in the specfile and the debian.rules files (flags used here). We can later update the script.

[jodh-intel]

It sounds like the script has bit-rotted slightly. Could you list the flags that are used in the script but which are not used by debian.rules and the specfile so we can work out what needs to be done to make configure-hypervisor.sh usable again?

[jodh-intel]

Hi @erick0z - as I've just raised kata-containers/packaging#7, could we revive this?

Step 1 would be to update configure-hypervisor.sh to reflect what we currently use for packaging. But we can then start trimming down the options to bring it back to the list of options currently in the script (which I think?) are more aggressive that we currently use for the packaged hypervisor.

We'll need to keep a close eye on performance and memory density for any changes made to the script.

/cc @grahamwhaley.

Given that there are a lot of options, and given that qemu atleast doesn't provide an option to dump its build config [*], I also wonder if it would make sense to include the output of configure-hypervisor.sh in the qemu-lite packages themselves in a file like:

/usr/share/qemu-lite/config.txt.gz

That file would contain a comment header then the options, one per line. It could be generated like this:

$ cat <<EOT > config.txt
# Source: https://github.com/clearcontainers/packaging/blob/master/scripts/configure-hypervisor.sh
# Commit: $commit_of_script
# Timestamp: $(date '+%Y-%m-%dT%T.%N%z')

$(/path/to/configure-hypervisor.sh -m qemu-lite)

EOT
$ gzip -9 config.txt

That file would allow tests / PnP to determine more easily the impact of different config options. It might make sense for this file to be created as:

/usr/share/clear-containers/qemu-config.txt.gz

... since that would avoid scripts having to find the correct directory for a particular hypervisor variant - they would always know where to look.

---

[*] - an alternative approach might be to "patch in" a new option to qemu like --dump-config, but that is ugly and has a maintenance cost.