Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

qemu: Automatically create swtpm device #1834

Merged
merged 1 commit into from Nov 26, 2021

Conversation

kalikiana
Copy link
Member

@kalikiana kalikiana commented Oct 22, 2021

  • Create device if QEMUTPM is set
  • Recommend swtpm packages

See: https://progress.opensuse.org/issues/101015

backend/qemu.pm Outdated Show resolved Hide resolved
dist/rpm/os-autoinst.spec Outdated Show resolved Hide resolved
backend/qemu.pm Outdated Show resolved Hide resolved
backend/qemu.pm Outdated Show resolved Hide resolved
@kalikiana kalikiana force-pushed the qemutpm_device branch 3 times, most recently from 9bd83cd to 813154f Compare October 25, 2021 16:01
@kalikiana kalikiana marked this pull request as ready for review October 25, 2021 16:02
@codecov
Copy link

codecov bot commented Oct 25, 2021

Codecov Report

Merging #1834 (7ae93f9) into master (2585008) will increase coverage by 0.10%.
The diff coverage is 63.15%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1834      +/-   ##
==========================================
+ Coverage   67.36%   67.47%   +0.10%     
==========================================
  Files          62       62              
  Lines        6877     6887      +10     
==========================================
+ Hits         4633     4647      +14     
+ Misses       2244     2240       -4     
Impacted Files Coverage Δ
backend/qemu.pm 51.40% <63.15%> (+0.98%) ⬆️
consoles/virtio_terminal.pm 98.64% <0.00%> (+1.35%) ⬆️
backend/driver.pm 100.00% <0.00%> (+2.77%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2585008...7ae93f9. Read the comment docs.

backend/qemu.pm Outdated Show resolved Hide resolved
@kalikiana
Copy link
Member Author

FYI expecting one test failure for the "default" case. I'm guessing I'm missing something obvious but I can't make much sense of the output and I don't see the issue in my code.

Copy link
Contributor

@Martchus Martchus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose it would work but have you conducted a complete test run?

@kalikiana
Copy link
Member Author

FYI expecting one test failure for the "default" case. I'm guessing I'm missing something obvious but I can't make much sense of the output and I don't see the issue in my code.

Seems like that was artifacts from debug code I'd forgotten to revert. However I did forget to commit the update-deps changes.
Not sure what's causing the OBS error, though 🤔

error: /home/abuild/rpmbuild/SOURCES/os-autoinst.spec:154: Got a %endif with no %if

I suppose it would work but have you conducted a complete test run?

FYI the test here runs qemu and swtpm, although it doesn't examine the device further. I was going to run the test from poo#101015 but that deleted, and I couldn't find existing tests relying on swtpm. Trying to get that from Richard.

dist/rpm/os-autoinst.spec Outdated Show resolved Hide resolved
dependencies.yaml Outdated Show resolved Hide resolved
@okurz
Copy link
Member

okurz commented Nov 9, 2021

https://build.opensuse.org/package/show/devel:openQA:TestGithub:OPR-1834/os-autoinst shows that swtpm can not be resolved so this won't work. Do we actually need swtpm for testing? I would prefer if we don't need it at all. If you are just checking the log for what would be called I guess we should be ok :)

@kalikiana
Copy link
Member Author

kalikiana commented Nov 10, 2021

https://build.opensuse.org/package/show/devel:openQA:TestGithub:OPR-1834/os-autoinst shows that swtpm can not be resolved so this won't work. Do we actually need swtpm for testing? I would prefer if we don't need it at all. If you are just checking the log for what would be called I guess we should be ok :)

I think it's rather good to know that it works. And we run a real qemu already

If the benefit is not obvious enough, remember what checking for hypothetical commands got us for image compression

@mergify
Copy link
Contributor

mergify bot commented Nov 15, 2021

This pull request is now in conflicts. Could you fix it? 🙏

@kalikiana
Copy link
Member Author

I was confused why setup_tpm needed the re-defined sp and qemu_params_ofw doesn't. After fixing the deprecation message for nowait the test passes w/o it.

Copy link
Member

@okurz okurz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please rephrase the git commit message subject line to answer the "Why", not the "What". Consider reading the changelog on openqa.opensuse.org/changelog which only shows the git commit message subject line. Think about what you would want to read as a user.

Also, what changes did you apply regarding #1834 (comment) ?

It might be better to do d5b4b9d in a separate PR as changing the commands on the command line might introduce backward incompatible changes. You might fix a warning on Tumbleweed but introduce problems for older Leap or SLE for example.

@kalikiana
Copy link
Member Author

Also, what changes did you apply regarding #1834 (comment) ?

I made the dependency Tumbleweed-specific similar to what we do with e.g. opencv. We don't run the test on OBS either way.

dist/rpm/os-autoinst.spec Outdated Show resolved Hide resolved
@kalikiana kalikiana force-pushed the qemutpm_device branch 2 times, most recently from af02059 to f42df28 Compare November 16, 2021 18:05
@kalikiana
Copy link
Member Author

kalikiana commented Nov 16, 2021

I suppose it would work but have you conducted a complete test run?

FYI the test here runs qemu and swtpm, although it doesn't examine the device further. I was going to run the test from poo#101015 but that deleted, and I couldn't find existing tests relying on swtpm. Trying to get that from Richard.

openqa-clone-job --from http://openqa.suse.de --skip-deps --host http://openqa.suse.de 7619588 --skip-download _GROUP=0 CASEDIR="https://github.com/rfan1/os-autoinst-distri-opensuse.git#swtpm_test_only"
Created job #7691337: sle-15-SP4-Online-x86_64-Build61.1-create_swtpm_hdd@64bit -> http://openqa.suse.de/t7691337

Unfortunately it fails like so in thebuild_hdd module:

fpmS7
/tmp/scriptfpmS7.sh: line 1: ll: command not found

@rfan1 Can you confirm if this is the right reproducer?

@rfan1
Copy link
Contributor

rfan1 commented Nov 17, 2021

I suppose it would work but have you conducted a complete test run?

FYI the test here runs qemu and swtpm, although it doesn't examine the device further. I was going to run the test from poo#101015 but that deleted, and I couldn't find existing tests relying on swtpm. Trying to get that from Richard.

openqa-clone-job --from http://openqa.suse.de --skip-deps --host http://openqa.suse.de 7619588 --skip-download _GROUP=0 CASEDIR="https://github.com/rfan1/os-autoinst-distri-opensuse.git#swtpm_test_only"
Created job #7691337: sle-15-SP4-Online-x86_64-Build61.1-create_swtpm_hdd@64bit -> http://openqa.suse.de/t7691337

Unfortunately it fails like so in thebuild_hdd module:

fpmS7
/tmp/scriptfpmS7.sh: line 1: ll: command not found

@rfan1 Can you confirm if this is the right reproducer?

No problem, let me revise my code and see.

@rfan1
Copy link
Contributor

rfan1 commented Nov 17, 2021

I suppose it would work but have you conducted a complete test run?

FYI the test here runs qemu and swtpm, although it doesn't examine the device further. I was going to run the test from poo#101015 but that deleted, and I couldn't find existing tests relying on swtpm. Trying to get that from Richard.

openqa-clone-job --from http://openqa.suse.de --skip-deps --host http://openqa.suse.de 7619588 --skip-download _GROUP=0 CASEDIR="https://github.com/rfan1/os-autoinst-distri-opensuse.git#swtpm_test_only"
Created job #7691337: sle-15-SP4-Online-x86_64-Build61.1-create_swtpm_hdd@64bit -> http://openqa.suse.de/t7691337

Unfortunately it fails like so in thebuild_hdd module:

fpmS7
/tmp/scriptfpmS7.sh: line 1: ll: command not found

@rfan1 Can you confirm if this is the right reproducer?

No problem, let me revise my code and see.

@kalikiana you can start a new job with the below one and add needed "swtpm" configuration: :)

openqa-clone-job --from http://openqa.suse.de --skip-deps --host http://openqa.suse.de 7656835 --skip-download _GROUP=0 CASEDIR="https://github.com/rfan1/os-autoinst-distri-opensuse.git#swtpm_test_only"

@kalikiana
Copy link
Member Author

openqa-clone-job --from http://openqa.suse.de --skip-deps --host http://openqa.suse.de 7656835 --skip-download _GROUP=0 CASEDIR="https://github.com/rfan1/os-autoinst-distri-opensuse.git#swtpm_test_only"

That seems to work, see https://progress.opensuse.org/issues/101015#note-15

- Create device if QEMUTPM is set
- Recommend swtpm packages

See: https://progress.opensuse.org/issues/101015
@kalikiana
Copy link
Member Author

The test is not fully covered because of the if ($arch eq 'aarch64') { handling... this is not new code, though, I moved it into a new function, so I wonder why it wasn't covered before 🤔

Copy link
Member

@okurz okurz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so I wonder why [this code] wasn't covered before thinking

Because automated tests did not exist before 2021 maybe ;P

@Martchus
Copy link
Contributor

It is just that it looks like this branch is actually covered. Maybe the coverage (of the forked process) isn't collected.

@kalikiana kalikiana merged commit 755f4e5 into os-autoinst:master Nov 26, 2021
@okurz
Copy link
Member

okurz commented Nov 27, 2021

@kalikiana why did you merge now? I am ok if you merge and state why you want to overrule checks. IMHO would have been a good opportunity to increase test coverage beyond the patch coverage check limit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants