Bug 1099104 - [Build 20180625] YaST fails to copy ssh keys to new system
[Build 20180625] YaST fails to copy ssh keys to new system
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2
Other Other
: P3 - Medium : Normal (vote)
: ---
Assigned To: Knut Alejandro Anderssen González
Jiri Srain
Depends on:
  Show dependency treegraph
Reported: 2018-06-26 06:46 UTC by Dominique Leuenberger
Modified: 2022-02-24 14:50 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
kanderssen: needinfo? (dimstar)


Note You need to log in before you can comment on or make changes to this bug.
Description Dominique Leuenberger 2018-06-26 06:46:24 UTC
## Observation

openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-gnome+import_ssh_keys@64bit fails in

## Reproducible

Fails since (at least) Build [20180625](https://openqa.opensuse.org/tests/697056)

## Expected result

Last good: [20180623](https://openqa.opensuse.org/tests/696540) (or more recent)

## Further details

Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&version=Tumbleweed&flavor=DVD&machine=64bit&test=gnome%2Bimport_ssh_keys)
Comment 1 Knut Alejandro Anderssen González 2018-07-04 12:21:32 UTC
We modified the returned value of the client, so when some ssh file was copied or imported then we returned an object instead of nil.

In GA we returned nil


Whereas in master we are relying in copy_ssh_files return value:


Proposed fix:

Comment 2 Knut Alejandro Anderssen González 2018-07-04 12:36:11 UTC
I have uploaded the rpms and a dud with the proposed fix in order to be tested:


Could you confirm that the related test pass fine with the given fix?
Comment 3 Dominique Leuenberger 2018-07-04 12:55:19 UTC
okurz: do we have an easy way to run a test (Tumbleweed test) with a DUD on top to test this out?
Comment 4 Sergio Lindo Mansilla 2018-07-04 15:22:08 UTC
(In reply to Dominique Leuenberger from comment #3)
> okurz: do we have an easy way to run a test (Tumbleweed test) with a DUD on
> top to test this out?


I have manually tested the DUD from Knut and it works.

In openQA, I think it would be easier to test it with a self_update. For DUD a multi machine test would be needed, or handle a secondary virtual storage.

With a self_update we just need the repository created by OBS with the changes of the developer.

Assuming that this use case is to test changes on the development phase (before having an ISO, before having a staging project), after having a home? repository in OBS with the changes, you could clone this job https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&version=Tumbleweed&flavor=DVD&machine=64bit&test=gnome%2Bimport_ssh_keys overriding the SETTING **EXTRABOOTPARAMS**.

Comment 5 Sergio Lindo Mansilla 2018-07-04 15:35:33 UTC
Here I have a home repo with the changes from Knut as git patches applied over the current devel package: https://build.opensuse.org/package/show/home:SLindoMansilla:branches:YaST:Head/yast2-installation

And here a sample clone: https://openqa.opensuse.org/tests/702036#settings

Cloned with: ./script/clone_job.pl --skip-deps --host https://openqa.opensuse.org --from https://openqa.opensuse.org 701232 _GROUP=0 TEST=sergio-gnome+import_ssh_keys EXTRABOOTPARAMS=self_update="https://download.opensuse.org/repositories/home:/SLindoMansilla:/branches:/YaST:/Head/openSUSE_Tumbleweed insecure=1"

Let's see what it does.
Comment 6 Oliver Kurz 2018-07-04 20:43:15 UTC
Well, interesting idea but that failed in https://openqa.opensuse.org/tests/702036#step/welcome/8 because the repo is not trusted during the self-update step. We would need to trust this repo from openQA tests.

@Sergio I don't see the need for a multimachine test.

I don't see the problem using either the variable DUD_ADDONS as in https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/6d147c60fd2f848a0a84d4c777ade2aac27fcf46/tests/installation/dud_addon.pm or DUD as in https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/ca60f2800df55d31aeed8c0479b6bf6283e5feca/lib/bootloader_setup.pm#L502 . Honestly I don't know the difference

Trying with DUD:

openqa-clone-job --skip-download --skip-chained-deps --from https://openqa.opensuse.org --host https://openqa.opensuse.org 701912 TEST=okurz_1099104_gnome+import_ssh_keys BUILD=20180703:bsc1099104 _GROUP="Development Tumbleweed" DUD=https://w3.nue.suse.com/~kanderssen/bug_1099104/

-> Created job #702048: opensuse-Tumbleweed-DVD-x86_64-Build20180703-gnome+import_ssh_keys@64bit -> https://openqa.opensuse.org/t702048

that did not seem to work, https://openqa.opensuse.org/tests/702048#step/welcome/7 "Failed to load driver update". Don't have that much experience with DUD. Maybe I need to specify the full path to the DUD file, not directory:

openqa-clone-job --skip-download --skip-chained-deps --from https://openqa.opensuse.org --host https://openqa.opensuse.org 701912 TEST=okurz_1099104_gnome+import_ssh_keys BUILD=20180703:bsc1099104 _GROUP="Development Tumbleweed" DUD=https://w3.nue.suse.com/~kanderssen/bug_1099104/copy.dud

-> Created job #702049: opensuse-Tumbleweed-DVD-x86_64-Build20180703-gnome+import_ssh_keys@64bit -> https://openqa.opensuse.org/t702049

Also failed in similar fashion: https://openqa.opensuse.org/tests/702049#step/welcome/6

Looking at https://openqa.opensuse.org/tests/702049/file/serial0.txt this becomes quite obvious: openqa.opensuse.org can not access the suse internal DUD directory, duh. I don't have webspace available right away but if one of you have I guess using a command like above with the according path to an external web folder should work.
Comment 7 Sergio Lindo Mansilla 2018-07-05 08:27:57 UTC
Exactly, after your investigation you end up to my point. As you need to set up this external resource, and the requirement was "easy way".

1. Manually set up of DUD http resource
2. Or manually set up of DUD secondary storage resource
to avoid doing that each time we want to test it, it should be automated
1. openQA - Multi-Machine test with support server as DUD http resource
2. openQA - Prepare secondary HDD as DUD storage resource


- Manually set up of http rpm repository.
to avoid doing that each time we want to test it, it should be automated
- Let OBS create the rpm repository for you

So, for me, seld_update wins. But I failed to set up my example properly.
Comment 8 Knut Alejandro Anderssen González 2018-07-05 09:51:42 UTC
This bug will be fixed in yat2-4.1.5

The corresponding SR is https://build.opensuse.org/request/show/620640
Comment 9 Sergio Lindo Mansilla 2018-07-16 16:32:34 UTC
Verified on O3: https://openqa.opensuse.org/tests/706810#step/await_install/2