-
Notifications
You must be signed in to change notification settings - Fork 270
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
Test suite for iSCSI server and client #1074
Conversation
send_key "alt-n"; # next | ||
assert_screen 'iscsi-initiator-connected-targets'; | ||
send_key "alt-o"; # OK | ||
sleep 2; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We would like to use less sleep. Can you try to replace all "sleep"? I guess wait_still_screen works here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, I will try it
see inline comments |
another point: I did not see you enabling the test in the main.pm, only in sle12 branch. openSUSE distributions should have no problem running iSCSI tests, please check. |
7bdb408
to
9047355
Compare
Updated, it should work also for openSUSE, tested a bit Tumbleweed, but have to create all needles and check if shortcuts fit. server: http://10.100.98.90/tests/1139/modules/iscsi_server/steps/26 |
+1 to me, let others have a look, too |
SLES Tumbleweed: |
Multimachine testsuites, server test creates iscsi target and client test uses it
@sysrich please take a look |
@@ -857,6 +857,14 @@ else { | |||
} | |||
elsif (get_var("BOOT_HDD_IMAGE")) { | |||
loadtest "boot/boot_to_desktop.pm"; | |||
if (get_var("ISCSI_SERVER")) { | |||
set_var('INSTALLONLY', 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no idea why you're trying to set_var() here, but it won't work - not saved to vars.json...save_vars() already passed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, it did work and it is also in vars.json
Tumbleweed:
server: http://10.100.98.90/tests/1174
client: http://10.100.98.90/tests/1175
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, you're right, I'm outdated, even load_vars() was in start_vm, it's 2016!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bmwqemu::vars
will be updated anyway so I think test will work. Only thing is that you won't see this variable set in webui, which will bite @dzedro in few months.
Or am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have other variables that follow other variables - without them showing in the job_settings. I don't see the problem. But I would indeed factor this out of the load_ functions and put them in front of the save_vars to make this variable dependency more clearer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree but how do you track ideas like this? Do you rely on others to grab your suggestion and go ahead and if nothing happens you do it or if nobody cares it wil be forgotten and it might not have been that important after all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just plant my suggestion into the brain of the next one to touch main.pm and it will work out - if not, I might be the one after that one ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, no more comments from others so I accept this |
Test suite for iSCSI server and client
Multimachine testsuites, server test creates iscsi target and client test uses it
server: http://10.100.98.90/tests/1060
client: http://10.100.98.90/tests/1061
I just copied wait.pm from supportserver