openstack-crowbar: Add pci passthough option #3543
Conversation
kwu83tw
force-pushed
the
pci_test
branch
10 times, most recently
from
988003d
to
c093bf8
Compare
kwu83tw
force-pushed
the
pci_test
branch
2 times, most recently
from
cff77af
to
1c5194a
Compare
kwu83tw
force-pushed
the
pci_test
branch
2 times, most recently
from
c229220
to
f0c0880
Compare
| @@ -401,6 +401,11 @@ | |||
| default: '1' | |||
| description: set to 0 to not deploy aodh | |||
|
|
|||
| - string: | |||
| name: want_pci_passthrough | |||
There was a problem hiding this comment.
I think this is used seldomly enough, that you can drop this and use custom_settings='export want_pci_passthrough=1' in the template instead.
There was a problem hiding this comment.
Sure. I thought it's required to define in here in order to be consumed in this proposed ci job template. Did I miss anything?
There was a problem hiding this comment.
If you want to use its own argument for that, like the PR currently does, you need to define it. If you are fine with passing it through the custom_settings argument then you don't.
kwu83tw
force-pushed
the
pci_test
branch
3 times, most recently
from
6871efd
to
0d51b7b
Compare
kwu83tw
force-pushed
the
pci_test
branch
5 times, most recently
from
94d3422
to
3f2ca8d
Compare
kwu83tw
force-pushed
the
pci_test
branch
2 times, most recently
from
642ea13
to
0e28196
Compare
| return 0 | ||
| } | ||
|
|
||
| function oncontroller_retrieve_image |
There was a problem hiding this comment.
You're duplicating functionality already available in qa_crowbarsetup.sh. Please try to reuse the image used for testvm that is being set up here.
There was a problem hiding this comment.
I was trying to reuse the testvm generated from testsetup step for past few days. However, I run into situation that the testvm won't boot up properly if the device passing from compute is attached (the specific flavor which has pci passthru attribute set). The workaround will be tweaking it to unplug/replug the device during post boot up phase. So I go back to my original formula instead of touching too many parts in oncontroller_testsetup.
There was a problem hiding this comment.
I understand your pain, but we need to think about this from a customer perspective. We should treat this like a bug that needs fixing instead of trying to work around it in our CI by using a different image (Cirros instead of SLES) ? However, I also understand that we don't really test the PCI passthrough feature in a manner that's relevant to our customers, so I'm a bit conflicted about this.
Can you give me more details about why the JeOS image won't boot with a second volume attached ? Is it because it tries to boot from the PCI passthrough device instead of the ephemeral volume set up by OpenStack ? If it's something we can fix easily through cloud-init, we should definitely try that. If not, I agree that we should use your original approach.
| fi | ||
| } | ||
|
|
||
| function oncontroller_upload_image_to_glance |
There was a problem hiding this comment.
Same as above, please reuse the image upload logic used for testvm available here.
| fi | ||
| } | ||
|
|
||
| function oncontroller_setup_pci_passthru_vm |
There was a problem hiding this comment.
qa_crowbarsetup.sh already has some test automation logic that creates a testvm virtual machine, pings/ssh-es it and so on. You may need to create and use a PCI passthrough enabled flavor, but otherwise please try to reuse the testvm test automation logic here.
There was a problem hiding this comment.
Unfortunately, I'm not able to reuse testvm since I need some operations right after booting up VM.
| fi | ||
| } | ||
|
|
||
| function append_pci_passthru_filter |
There was a problem hiding this comment.
This function goes to a lot of trouble to just set one parameter in the nova proposal. Instead, why not add that parameter from the very beginning, when the proposal gets first created here ?
There was a problem hiding this comment.
It's part of the acceptance criteria for this Jira which is not introducing any change in Nova proposal for testing pci passthrough but sneak in the configuration when it is needed.
kwu83tw
force-pushed
the
pci_test
branch
11 times, most recently
from
c6c13f0
to
c9c7f4e
Compare
kwu83tw
force-pushed
the
pci_test
branch
3 times, most recently
from
8b5be41
to
3ab9900
Compare
Add Jenkins parameter 'want_pci_passthrough' to allow running tests to validate pci passthough. To test pci passthrough locally with mkcloud, simply just export 'want_pci_passthrouh=1' and append 'rebootcloud testpcipassthru' to 'plain' step, e.g. your_mkcloud.sh plain rebootcloud testpcipassthru The rebootcloud step will ensure intel_iommu=on kernel param enabled. The testpcipassthru step will prepare the environment and spin up a nested vm (L2) on compute (L1) with a virtio disk passing from compute vm (L1). Noted that this is not passing any device from the host (L0) itself. There will be another PR to construct job definition and other prep works for new ci. 1. add environment prep and verify function in qa_crowbarsetup.sh 2. create legacy ci job template 3. introduce testpcipassthru step in mkcloud
Add Jenkins parameter 'want_pci_passthrough' to allow running tests to validate pci passthough.