clearcontainers / packaging

Packaging data for Clear Containers
11 stars 11 forks source link

switch packaging to use configure-hypervisor.sh script #46

Open jodh-intel opened 7 years ago

jodh-intel commented 7 years ago

:warning: 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:

jodh-intel commented 7 years ago

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

gorozco1 commented 7 years ago

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

grahamwhaley commented 7 years ago

let me see if I can do that...

grahamwhaley commented 7 years ago

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

gorozco1 commented 7 years ago

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

jodh-intel commented 7 years ago

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, https://github.com/clearcontainers/tests/pull/696.

erick0z commented 7 years ago

@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 commented 6 years ago

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 commented 6 years ago

Hi @erick0z - as I've just raised https://github.com/kata-containers/packaging/issues/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.