action #19566
closed[sle][functional]New test scenario: minimal+proxy_SCC-postreg_suseconnect_scc
0%
Description
Updated by Anonymous over 7 years ago
- Status changed from New to In Progress
- Assignee set to Anonymous
Updated by Anonymous over 7 years ago
- Status changed from In Progress to Resolved
The scenario is gone. Neither in openqa.suse.de nor openqa.opensuse.org testsuite database any more.
Updated by okurz over 7 years ago
- Status changed from Resolved to In Progress
yi, please don't do that. The testsuite "minimal+base+sdk+proxy_SCC-postreg" still exists in https://openqa.suse.de/admin/test_suites and if it would be gone we must not just accept this but be very careful that we are not loosing anything from our test coverage. I already added a description to the test suite. I don't know why it's not in test development anymore but feel free to add it back. Could you check the test for the tasks I suggested in the original ticket description?
Updated by Anonymous about 7 years ago
The scenario is called minimal+base+sdk+proxy_SCC-postreg, belonging to job group Functional: Server.
Here is an example testrun: https://openqa.suse.de/tests/1058256
Updated by Anonymous about 7 years ago
For SLE15 it already exists: https://openqa.suse.de/tests/1119787
Updated by okurz about 7 years ago
please update tickets "In Progress" at latest EOB (end of business day) with either having it resolved - of course preferred ;-) - or with a clear comment why it was not finishable within the day.
Updated by Anonymous about 7 years ago
Updated by okurz about 7 years ago
- Related to action #25352: [sle][functional]test fails in yast_scc - scenario minimal+base+sdk+proxy_SCC-postreg added
Updated by okurz about 7 years ago
- Subject changed from New test scenario: minimal+base+sdk+fakescc-postreg to New test scenario: minimal+base+sdk+proxy_SCC-postreg (was: minimal+base+sdk+fakescc-postreg)
- Description updated (diff)
- Priority changed from Normal to High
With SLE15 and more product changes this scenario gets more important so IMHO we should bump prio.
Updated the description with acceptance criteria and updated tasks. That should help to go forward.
Updated by mgriessmeier about 7 years ago
Updated by okurz about 7 years ago
- Subject changed from New test scenario: minimal+base+sdk+proxy_SCC-postreg (was: minimal+base+sdk+fakescc-postreg) to [sle][functional]New test scenario: minimal+base+sdk+proxy_SCC-postreg (was: minimal+base+sdk+fakescc-postreg)
Updated by riafarov about 7 years ago
Test module code can be found here: https://github.com/yxususe/os-autoinst-distri-opensuse/blob/proxyscc_postreg/tests/console/suseconnect_scc.pm
Updated by Anonymous about 7 years ago
A new test scenario will be created. Verification testrun: http://f146.suse.de/tests/1352 http://f146.suse.de/tests/1353
Updated by okurz about 7 years ago
As discussed with yi and riafarov I reminded about the suggestions in the ticket description. I recommend to try a test plan that should look as simple as:
- boot_to_desktop
- suseconnect_scc
and another test suite with:
- boot_to_desktop
- yast_scc
If necessary add additional modules - but only if necessary - e.g. sle15_workarounds or consoletest_setup or hostname. If the above is done - but only after it's done - you can add more test modules, e.g. "zypper_lr" to list the enabled repositories.
Updated by Anonymous about 7 years ago
Updated by okurz about 7 years ago
- Due date changed from 2017-10-11 to 2017-10-25
have to use double ticks in script_run 'SUSEConnect -r $reg_code';
and use assert_script_run -> assert_script_run "SUSEConnect -r $reg_code";
@riafarov, @yi
Updated by Anonymous about 7 years ago
PR updated. Verification testruns are: http://f146.suse.de/tests/1454 http://f146.suse.de/tests/1455
At the moment the test fails because the repos couldn't be refreshed.
Updated by Anonymous about 7 years ago
Testsuites are added. However cannot be executed yet because qcow images are not available.
Updated by okurz about 7 years ago
failed as incomplete on zkvm: https://openqa.suse.de/tests/1209421
Please make sure to not keep scenarios that end up incomplete
Updated by okurz about 7 years ago
https://openqa.suse.de/tests/1209422#step/boot_to_desktop/2 is the failing scenario you added for zVM. This cannot work as zVM instances can not boot disk images. Also the scenario does not state 'START_AFTER_TEST. This won't work. I suggest to use the "test development" job group for experiments.
Updated by Anonymous about 7 years ago
- Status changed from In Progress to Feedback
Because qcow images are missing which results incomplete testruns, I changed the ticket status to feedback.
Updated by okurz about 7 years ago
Keep in mind though that jobs should not incomplete. If that is the case then they are incorrectly configured. Rather they should cancel if the parent job fails to provide a qcow image, which they do: https://openqa.suse.de/tests/1213106
So ok up to now. Also most recent build 303.1 could not provide a qcow image so understandable that we are blocked by this still.
A workaround is to retrigger an older build which still worked.
Updated by Anonymous about 7 years ago
- Status changed from Feedback to In Progress
Updated by okurz about 7 years ago
@yi please update the ticket description with more recent tasks and an effort estimation according to the template as we also have it in other tickets.
Updated by Anonymous about 7 years ago
Atm the test fails at boot_to_desktop since it didn't boot to desktop but only text mode:
https://openqa.suse.de/tests/1226927#step/boot_to_desktop/6
However I couldn't reproduce it locally, reasons: when I copied the job, it is scheduled after skip_registration, which already fails at first_boot, so that the test couldn't continue.
Besides that, can anyone tell me the reason for scheduling it after skip_registration?
Updated by Anonymous about 7 years ago
- Subject changed from [sle][functional]New test scenario: minimal+base+sdk+proxy_SCC-postreg (was: minimal+base+sdk+fakescc-postreg) to [sle][functional]New test scenario: minimal+proxy_SCC-postreg (was: minimal+base+sdk+fakescc-postreg)
- Description updated (diff)
Updated by Anonymous about 7 years ago
Trying with DESKTOP=textmode:
geekotest@shaka:~> /usr/share/openqa/script/clone_job.pl --from https://openqa.suse.de --host https://openqa.suse.de --skip-download --skip-deps 1226927 DESKTOP=textmode _GROUP=0 TEST=postreg_scc_yxu_tryout_with_desktop_textmode
Created job #1227554: sle-15-Installer-DVD-x86_64-Build310.1-minimal+proxy_SCC-postreg_SUSEconnect@64bit
Updated by Anonymous about 7 years ago
There's dependency issues between modules, the source code should be fixed.
Updated by okurz about 7 years ago
Yes, I think either use @mnowak's code or in case of suseconnect_scc.pm instead of
foreach (values %registration::SLE15_MODULES) {
assert_script_run "SUSEConnect -p sle-module-" . lc($_) . "/$version/$arch";
}
it should be
foreach (split(',', $registration::SLE15_DEFAULT_MODULES{get_required_var('SLE_PRODUCT')})) {
assert_script_run "SUSEConnect -p sle-module-" . lc($registration::SLE15_MODULES{$_}) . "/$version/$arch";
}
(code not verified)
to
- use the default modules only
- support all products
- use the correct order of modules
Updated by okurz about 7 years ago
"time inestimably": Easy suggestion: When you can't find a time estimation stop work immediately. What's the sense to start a work when you don't know if you can ever finish? I think you can find an effort estimation (not duration) with a <optimistic>-<pessimistic>
range.
"…because of other dependent issues": which ones?
yi: issue was mentioned in comment 31, now resolved.
Updated by Anonymous about 7 years ago
PTF submitted. Now I will try to adapt the code form sccreg.pm.
Updated by Anonymous about 7 years ago
I had a look of lib/suseconnect_register.pm, it will be more complicated to call one function command_register from there, since it uses SCC_ADDONS as the queue of modules to be registered and the modules are also kept in hash.
Another look at jeos/sccreg.pm: it is very similar to console/suseconnect_scc.pm, the only difference is that the modules for jeos are: ('basesystem', 'scripting', 'legacy'), so there should be a way to reduce code redundancy here actually. However this PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/3776 should fix the problem for now.
Verification testruns on osd: http://openqa.suse.de/tests/1230963 http://openqa.suse.de/tests/1230964
Updated by SLindoMansilla about 7 years ago
- Description updated (diff)
yxi, how can I help you with this?
I see that the current step to do is fixing the problem about missing yast2 on SLE15 minimal for the module yast_scc.
Updated by okurz about 7 years ago
the scenario "yast_scc" can not work this way as the HDD image does not provide yast (and should not). I removed the scenario from the functional job group and instead moved it to Test Development: SLE 15 (64bit only). The suseconnect scenario for zkvm was incomplete because there is no "skip_registration@zkvm", only "skip_registration@s390x-kvm". Added the corresponding scenario to Test Development: SLE 15 as well.
Updated by SLindoMansilla about 7 years ago
- Related to action #26042: [sle][functional][sle15] new system role - "textmode" added
Updated by SLindoMansilla about 7 years ago
- Related to action #23408: [sle][functional]Use single test suite for create_hdd_textmode on all architectures added
Updated by SLindoMansilla about 7 years ago
Providing a basis: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/3781
A lot to be improved yet.
Updated by Anonymous about 7 years ago
Oliver, the content of SLE15_MODULES and SLE15_DEFAULT_MODULES are different, and the naming matters: http://openqa.suse.de/tests/1230963#step/suseconnect_scc/16 . Could you explain why you are using SLE15_DEFAULT_MODULES instead of SLE15_MODULES? And I think the easiest way is still to define the modules just in an array.
Updated by Anonymous about 7 years ago
- Subject changed from [sle][functional]New test scenario: minimal+proxy_SCC-postreg (was: minimal+base+sdk+fakescc-postreg) to [sle][functional]New test scenario: minimal+proxy_SCC-postreg_suseconnect_scc
- Description updated (diff)
Updated by Anonymous about 7 years ago
Hi Sergio, I have separated the scenario minimal+proxy_SCC-postreg_yast_scc in another ticket: https://progress.opensuse.org/issues/26984
And since you are already working on it, I assigned it to you. Thanks.
Updated by Anonymous about 7 years ago
- Related to deleted (action #25352: [sle][functional]test fails in yast_scc - scenario minimal+base+sdk+proxy_SCC-postreg )
Updated by Anonymous about 7 years ago
- Related to deleted (action #26042: [sle][functional][sle15] new system role - "textmode")
Updated by Anonymous about 7 years ago
- Related to deleted (action #23408: [sle][functional]Use single test suite for create_hdd_textmode on all architectures)
Updated by okurz about 7 years ago
- Related to action #26984: [sle][functional][y] New test scenario: minimal+proxy_SCC-postreg_yast_scc added
Updated by okurz about 7 years ago
- Due date changed from 2017-10-25 to 2017-11-08
Yes, the ticket split makes sense now. So with this I feel confident that we can resolve the ticket within sprint 3 :) As agreed with PO -> sprint 3
Updated by Anonymous about 7 years ago
Last verification on osd failed although on my local machine succeeded. New verification: http://openqa.suse.de/tests/1233670
Updated by Anonymous about 7 years ago
- Status changed from In Progress to Resolved
Verification testrun succeeded.
Updated by okurz about 7 years ago
That's good! The last job within the QA SLE functional job group https://openqa.suse.de/tests/1233455 failed however to boot an image. Ideas why?
Updated by Anonymous about 7 years ago
Because the needle was lost? It couldn't boot. Should there some more parameters be specified? But on aarch64 it succeeded: https://openqa.suse.de/tests/1233047#step/boot_to_desktop/1
Updated by okurz about 7 years ago
https://openqa.suse.de/tests/1233455#step/boot_to_desktop/2 does not look like any needle was lost
Updated by Anonymous about 7 years ago
Verified with build 321.5:
https://openqa.suse.de/tests/1236202
https://openqa.suse.de/tests/1235877
https://openqa.suse.de/tests/1235712