action #119662
closedcoordination #121876: [epic] Handle openQA review failures in Yam squad - SLE 15 SP5
openldap_to_389ds module failed because of dependency issue
Added by jgwang about 2 years ago. Updated over 1 year ago.
0%
Description
Motivation¶
some openldap_to_389ds module failed on x86_64, this is a failed job:
https://openqa.suse.de/tests/9825912#step/openldap_to_389ds/14
it is a dependency issue, this is the related bug:
https://bugzilla.suse.com/show_bug.cgi?id=1203835
rpm -i openldap2-2.4.46-150000.9.74.3.x86_64.rpm
error: Failed dependencies:
libldap-2_4-2 = 2.4.46-150000.9.74.3 is needed by openldap2-2.4.46-150000.9.74.3.x86_64
Acceptance criteria¶
AC1: find resolution to make "openldap_to_389ds" pass
Updated by jgwang about 2 years ago
- Related to coordination #61780: [functional][y][epic] test update for yast-samba re 389-ds added
Updated by coolgw about 2 years ago
One solution is we can split openldap_to_389ds.pm into two parts and running in service check frame work. Then first part is using openldap create data base file, second part(do openldap->389 migration work) will be called after migration.
# Prepare data file for migration
assert_script_run "sed -i 's/^root_password.*/root_password = $password/' ./instance.inf";
assert_script_run "mkdir slapd.d";
assert_script_run("dscreate from-file ./instance.inf", timeout => 180);
assert_script_run("echo '127.0.0.1 susetest' >> /etc/hosts");
assert_script_run "dsctl localhost status";
assert_script_run "slaptest -f slapd.conf -F ./slapd.d";
---------------------------------split here-------------------------------------
# Check migration tools
$self->tar_and_upload_log('./slapd.d', 'slapd.d.tar.bz2');
upload_logs("./db.ldif", timeout => 100);
upload_logs("./slapd.conf", timeout => 100);
assert_script_run "openldap_to_ds -v --confirm localhost ./slapd.d ./db.ldif > ldap2dslog";
upload_logs("./ldap2dslog", timeout => 100);
assert_script_run "ldapmodify -H ldap://localhost -x -D 'cn=Directory Manager' -w $password -f aci.ldif";
Updated by openqa_review about 2 years ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: offline_sles12sp4_ltss_media_sdk-lp-we-asmm-contm-lgm-tcm-wsm-pcm_all_full
https://openqa.suse.de/tests/9920430#step/openldap_to_389ds/1
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released" or "EOL" (End-of-Life)
- The bugref in the openQA scenario is removed or replaced, e.g.
label:wontfix:boo1234
Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.
Updated by openqa_review almost 2 years ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: offline_sles12sp4_ltss_media_sdk-lp-we-asmm-contm-lgm-tcm-wsm-pcm_all_full
https://openqa.suse.de/tests/10089274#step/openldap_to_389ds/1
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released" or "EOL" (End-of-Life)
- The bugref in the openQA scenario is removed or replaced, e.g.
label:wontfix:boo1234
Expect the next reminder at the earliest in 56 days if nothing changes in this ticket.
Updated by openqa_review almost 2 years ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: offline_sles12sp4_ltss_media_sdk-lp-we-asmm-contm-lgm-tcm-wsm-pcm_all_full
https://openqa.suse.de/tests/10437153#step/openldap_to_389ds/1
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released" or "EOL" (End-of-Life)
- The bugref in the openQA scenario is removed or replaced, e.g.
label:wontfix:boo1234
Expect the next reminder at the earliest in 112 days if nothing changes in this ticket.
Updated by JERiveraMoya almost 2 years ago
- Status changed from New to Workable
- Target version set to Current
Updated by syrianidou_sofia almost 2 years ago
- Status changed from Workable to In Progress
- Assignee set to syrianidou_sofia
Updated by JERiveraMoya almost 2 years ago
- Priority changed from Normal to High
Updated by syrianidou_sofia almost 2 years ago
PR where openldap_to_ds module is split: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/16505
Also adding MEGIA_UPGRADE: '0' for the non media upgrade tests so they can load the openldap modules through the conditional schedule
https://gitlab.suse.de/coolgw/wegao-test/-/merge_requests/250/diffs
Updated by syrianidou_sofia over 1 year ago
- Status changed from In Progress to Resolved
Opened https://progress.opensuse.org/issues/125717 for the sporadic failures regarding configuration validation.
Updated by openqa_review over 1 year ago
- Status changed from Resolved to Feedback
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: online_sles15sp3_pscc_lp-we-basesys-srv-desk-dev-contm-lgm-tsm-wsm-pcm_all_full
https://openqa.suse.de/tests/10720738#step/openldap_to_389ds/1
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released" or "EOL" (End-of-Life)
- The bugref in the openQA scenario is removed or replaced, e.g.
label:wontfix:boo1234
Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.
Updated by syrianidou_sofia over 1 year ago
- Status changed from Feedback to Resolved
openqa automatically linked this ticket with a new failure, but we have https://progress.opensuse.org/issues/125717 specifically for this failure