Skip to content
This repository has been archived by the owner on May 6, 2020. It is now read-only.

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

Open
jodh-intel opened this issue Aug 11, 2017 · 9 comments
Open

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

jodh-intel opened this issue Aug 11, 2017 · 9 comments
Assignees

Comments

@jodh-intel
Copy link

jodh-intel commented Aug 11, 2017

⚠️ 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
Copy link
Author

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

@gorozco1
Copy link

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

@grahamwhaley
Copy link
Contributor

let me see if I can do that...

@grahamwhaley
Copy link
Contributor

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

@gorozco1 gorozco1 assigned erick0z and unassigned gorozco1 Sep 5, 2017
@gorozco1
Copy link

gorozco1 commented Sep 5, 2017

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

@jodh-intel
Copy link
Author

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
Copy link

erick0z commented Nov 15, 2017

@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
Copy link
Author

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
Copy link
Author

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.

egernst pushed a commit to egernst/cc-packaging that referenced this issue Aug 14, 2018
…rsion-pgs

pkg: kernel: Add kernel config version to pkg version.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants