coordination #17436
closed[tools][functional][y][epic] tests must not have access to published repos, e.g. download.o.o on Tumbleweed -> remove all references to download.o.o from repos during installation and afterwards
Added by okurz about 7 years ago. Updated over 3 years ago.
100%
Description
acceptance criteria¶
- AC1: Only repository content from openqa.opensuse.org is used for all openSUSE tests after installation
- AC2: Same as AC1 but for the installer system itself
tasks¶
- check test cases for the execution of tests/update/zypper_clear_repos.pm and see if the same approach can be adapted for a generic approach (1-2h)
- start by selecting a standard gnome/kde test suite and any extra tests scenario, make sure the online repos not pointing to openqa.opensuse.org are disabled and check if all packages can still be installed (2-4h)
- rewrite all occurences of "download.opensuse.org" in the SUT to the according path pointing to openqa.opensuse.org, e.g. with a test module that calls sed -i -e 's/download.opensuse.org/…/g' /etc/zypp/repos.d/* in the installed system (2-8h)
- investigate how repos are used in the installer system, replace occurences of download.opensuse.org as described above or not add any online repos there if possible (2-16h)
further details¶
observation¶
see for example https://bugzilla.suse.com/show_bug.cgi?id=1026767. This bug was just "found" by openQA when also users reported this. The reason is probably that the tests still have published repos from download.opensuse.org enabled causing an upgrade to find packages from either the new snapshot or the old published data which can make tests pass when they shouldn't. Then the tests fail in the subsequent snapshot because the repos were updated in the meantime.
proposal¶
proposal by nussel in #17818
On openSUSE the 'crash' test doesn't work as the debuginfo repo is not mirrored to openqa. So whenever the kernel gets updated that test fails due to a mismatch between the installed kernel and the debug information in the debuginfo repo.
openQA should keep a local copy of all repos and intercept access to download.opensuse.org so files are downloaded from matching repos actually.
from #17926
Follow up to bug https://bugzilla.opensuse.org/show_bug.cgi?id=1030759
The problem:
whlie testing upgrade scenarios from e.g. 42.2 to TW-Next (the version being tested in openQA), the CURRENTLY published TW on download.o.o is ALSO taken into account (online repo enabled)
In case of the boo#1030759 this results in the updater NOT tagging libmutter0 is an obsolete package (it is tagged 'weakremove', which means it is ONLY marked for deletion if it is NOT found in any of the enabled repos. As TW (published) still contains the package, it is not removed - furhter blocking the update of gnome-shell * mutter, which leads to the test failures as seen in e.g. https://openqa.opensuse.org/tests/375730
We had seen similar test issues in the past, be it that stuff 'works' during the openQA test until TW-Next is published (then packages disappear, and tests would no longer pass)
In any case, having the repo published at download.o.o available to the tests is defeating openQA as it is intended totally, as many tests are not reliable this way (testing a repo combination that no user will possibly be able to have on his system)
https://openqa.opensuse.org/tests/375730#step/upgrade_select_opensuse/2 Shows that the repos are in fact enabled. https://openqa.opensuse.org/tests/375807#step/start_install/18 is an example from the 'other direction of the same problem'. With snapshot 0320, libmarco-private0 was dropped (replaced by libmarco-private1); when 0320 was being tested though, the previously published snapshot was available and thus this did not show an error in its test run at https://openqa.opensuse.org/tests/374330. As soon as snapshot 0320 has been published, the available package list changed and the test is thus invalid (and fails with one day delay). After 0322 was published, reran the 42.2-> tw update passed. before publish: https://openqa.opensuse.org/tests/375730 vs after publish and rerun: https://openqa.opensuse.org/tests/376303#
The whole openSUSE Factory snapshot should be synced to o3 and probably the same for Leap so all repository content should be there on o3.
Files
| blockage_install_mc.png (41 KB) blockage_install_mc.png | zypper in mc | EDiGiacinto, 2017-06-14 15:09 | |
| blocks_dnsmasq.png (41.6 KB) blocks_dnsmasq.png | zypper in dnsmasq | EDiGiacinto, 2017-06-14 15:09 | |
| canvas2.png (26.9 KB) canvas2.png | zypper in nano | EDiGiacinto, 2017-06-14 15:09 | |
| packages_are_available.png (45.3 KB) packages_are_available.png | zypper se mc | EDiGiacinto, 2017-06-14 15:09 | |
| package_block_terminator.png (12.6 KB) package_block_terminator.png | zypper in terminator | EDiGiacinto, 2017-06-14 15:09 |
Updated by okurz about 7 years ago
- Copied from action #16618: [qe-core][opensuse][functional] Tumbleweed upgrade tests added
Updated by okurz about 7 years ago
The offline upgrade case opensuse-Tumbleweed-DVD-x86_64-Build20170225-update_13.2@64bit enables online repos, that's wrong, right? Should we disable the online repos after "testing" that the installer enables them by default by introducing a test specific step, switching to the shell in the installer system and disabling repos again? I wonder if the installer would get confused by this. If we can't change that then the scenario should be moved into a post-published test group, see #16618, right?
Updated by okurz about 7 years ago
- Assignee deleted (
okurz) - Priority changed from High to Normal
discussed in openQA coordination call 2017-03-03. A good approach might be an "proxy-download.o.o" which can intercept all downloads. We can disable some online repos as we sync DVD+oss and have these available as repos during testing but maybe we won't have all packages available. Hmm.
Updated by RBrownSUSE about 7 years ago
- Project changed from openQA Tests to openQA Project
- Subject changed from Tumbleweed tests must not have access to published repos to [tools]Tumbleweed tests must not have access to published repos
- Category deleted (
Bugs in existing tests)
Moving to correct project and tagging
This is not something which can only be implemented into the tests, will need enablement on the backend side to make it work
Updated by okurz about 7 years ago
- Has duplicate action #17818: mirror and redirect all repos on openqa added
Updated by okurz about 7 years ago
- Project changed from openQA Project to openQA Tests
- Subject changed from [tools]Tumbleweed tests must not have access to published repos to [tools] tests must not have access to published repos, e.g. Tumbleweed -> mirror all on openQA instance?
- Description updated (diff)
rbrown, I don't see the relation to backend. There might be repositories being injected by rsync.pl - not part of openQA project - but the main problem is very likely in the tests distribution, e.g. upgrade of installer adds opensuse oss repo. If you want to have a '[tools]' tag, fine. But it has nothing to do with either os-autoinst nor openQA.
Updated by michalnowak about 7 years ago
- Has duplicate action #18070: [opensuse][leap][kernel][functional][tools] test fails in crash because it can not find the debuginfo package added
Updated by michalnowak about 7 years ago
- Has duplicate deleted (action #18070: [opensuse][leap][kernel][functional][tools] test fails in crash because it can not find the debuginfo package)
Updated by michalnowak about 7 years ago
- Related to action #18070: [opensuse][leap][kernel][functional][tools] test fails in crash because it can not find the debuginfo package added
Updated by okurz about 7 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: extra_tests_in_textmode
https://openqa.opensuse.org/tests/380906
Updated by okurz about 7 years ago
- Has duplicate action #17926: [tools]Tumbleweed upgrade tests have download.o.o repos enabled added
Updated by lnussel about 7 years ago
Also affects yast2_clone_system as soon as autoyast gets updated as autoyast in the online repo and autoyast2-installation as shipped with the installation don't match anymore.
Updated by okurz almost 7 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: yast2_ui
https://openqa.opensuse.org/tests/407154
Updated by SLindoMansilla almost 7 years ago
- Assignee set to SLindoMansilla
- Target version set to Milestone 8
Updated by okurz almost 7 years ago
If I understood correctly the whole factory snapshot is synced to o3 and probably the same for Leap so I suggest you start by selecting a standard gnome/kde test suite and any extra tests scenario, make sure the online repos not pointing to openqa.opensuse.org are disabled and check if all packages can still be installed.
Updated by RBrownSUSE almost 7 years ago
- Assignee changed from SLindoMansilla to EDiGiacinto
Ettore will be looking at this also to fix this issue from the backend side of things
Updated by okurz almost 7 years ago
- Status changed from New to In Progress
as discussed, if possible it would be good if the "network isolation" can be controlled by a variable to switch on/off. If that is not possible or too much effort a "hack" would be to rewrite all occurences of "download.opensuse.org" to the according path pointing to openqa.opensuse.org, e.g. with a test module that calls sed -i -e 's/download.opensuse.org/…/g' /etc/zypp/repos.d/* in the installed system and the equivalent in the installation system or not add any online repos there if possible
Updated by SLindoMansilla almost 7 years ago
Hello Ettore,
Since this ticket blocks https://progress.opensuse.org/issues/15932
Please, inform me when you finished this. ;)
Regards.
Updated by EDiGiacinto almost 7 years ago
Small update:
I made a PoC that consist in two new components in the backend that can proxy/redirect http connections of the guest vm (limited support to QEMU user mode as for now, it's still a PoC!) . The test involved redirecting all d.o.o connections to the openQA mirrored one in assets/repo. While fetching data worked, during the test, unfortunately the YaST2 UI freezes when accepting the first license, hence opened a bug: https://bugzilla.suse.com/show_bug.cgi?id=1044254.
Local test can be found at: http://10.100.51.88/tests/345
Updated by EDiGiacinto almost 7 years ago
- Status changed from In Progress to Feedback
Updated by EDiGiacinto almost 7 years ago
- File blockage_install_mc.png blockage_install_mc.png added
- File blocks_dnsmasq.png blocks_dnsmasq.png added
- File canvas2.png canvas2.png added
- File package_block_terminator.png package_block_terminator.png added
- File packages_are_available.png packages_are_available.png added
Did further investigations, after chrooting on the system that has to be upgraded (always refeering to the same test) i tried to manually add the repository d.o.o (which redirects to openqa mirrored one) and run zypper to install some packages.
The good news is that the the approach seems to work, since i can fetch the repo for metadata and having it installed in the system; on the other side the bad news is we have even more conflicts than with having the d.o.o. repository enabled without redirection, making impossible to install a simple package or upgrade the whole system.
At this point one idea could be to serve an empty repository instead, or having an empty repository mirrored somewhere and redirect the request there, but i see it that it's getting more as a big hack from the backend side (althought it would probably solve the YaST2 UI freezes).
I'm attaching few screenshots how dependency calculation is "stuck" with almost no viable solution in most cases.
os-autoinst logs shows anyway that redirection has been handled as expected:
15:02:41.6499 15940 >> DNS Server: Intercepting request for download.opensuse.org
15:02:41.6501 15940 >> DNS Server: Answer download.opensuse.org. IN A 10.0.2.254
15:02:41.6504 15940 >> DNS Server: Intercepting request for download.opensuse.org
15:02:41.6506 15940 >> DNS Server: Answer download.opensuse.org. IN A 10.0.2.254
15:02:41.6518 15941 >> backend::component::proxy Request from: 127.0.0.1 method: GET to host:download.opensuse.org
15:02:41.6519 15941 >> backend::component::proxy Requested url is: /tumbleweed/repo/oss/repodata/repomd.xml.asc
15:02:41.6522 15941 >> backend::component::proxy Redirecting to: http://openqa.opensuse.org/assets/repo/openSUSE-Tumbleweed-oss-i586-x86_64-Snapshot20170610/suse/repodata/repomd.xml.asc
15:02:41.7104 15941 >> backend::component::proxy Request from: 127.0.0.1 method: GET to host:download.opensuse.org
15:02:41.7105 15941 >> backend::component::proxy Requested url is: /tumbleweed/repo/oss/repodata/repomd.xml.key
15:02:41.7111 15941 >> backend::component::proxy Redirecting to: http://openqa.opensuse.org/assets/repo/openSUSE-Tumbleweed-oss-i586-x86_64-Snapshot20170610/suse/repodata/repomd.xml.key
15:02:41.7548 15941 >> backend::component::proxy Request from: 127.0.0.1 method: GET to host:download.opensuse.org
15:02:41.7551 15941 >> backend::component::proxy Requested url is: /tumbleweed/repo/oss/repodata/repomd.xml
15:02:41.7565 15941 >> backend::component::proxy Redirecting to: http://openqa.opensuse.org/assets/repo/openSUSE-Tumbleweed-oss-i586-x86_64-Snapshot20170610/suse/repodata/repomd.xml
15:02:41.8295 15941 >> backend::component::proxy Request from: 127.0.0.1 method: GET to host:download.opensuse.org
15:02:41.8296 15941 >> backend::component::proxy Requested url is: /tumbleweed/repo/oss/repodata/fe04c70d375f6737d3df02ab1da0224aa1b567c52412382ffc8d74f12b409554-primary.xml.gz
15:02:41.8299 15941 >> backend::component::proxy Redirecting to: http://openqa.opensuse.org/assets/repo/openSUSE-Tumbleweed-oss-i586-x86_64-Snapshot20170610/suse/repodata/fe04c70d375f6737d3df02ab1da0224aa1b567c52412382ffc8d74f12b409554-primary.xml.gz
Updated by EDiGiacinto almost 7 years ago
PR with the required components will be issued soon, for sure by the end of the week. For the yast UI freeze got no answers yet.
Updated by EDiGiacinto almost 7 years ago
Updated by okurz almost 7 years ago
To my understanding what we identified during the work on this ticket is that we need to understand all connections that a SUT makes to any external ressource to fully cover this. So regardless of the technical solution we would need to identify and intervene e.g. the installation system, zypper, yast, etc. whenever it tries to establish an external connection. IMHO during the "qa sle tools retrospective" we came to the conclusion that the originally proposed feature within os-autoinst will offer some advantages but also disadvantages and does not solve the original problem really different. So the current recommendation is "back to tests", i.e. we need to make sure within os-autoinst-distri-opensuse to intercept and change the repo connections, e.g. by providing a proxy in installation, changing online repos using the yast installer GUI for "online repositories" as well as in installed systems changing the zypper repo configuration.
@EDiGiacinto: Please update the ticket from your side, at least unassign if you do not plan to solve the initial issue the way I proposed
Updated by EDiGiacinto almost 7 years ago
- Assignee deleted (
EDiGiacinto)
As discussed in the retrospective call, the solution that could be provided from the backend side it's too invasive and will require changes in the tests side as well.
I'm removing myself as assigned since this now should be solved by maintainers of the different test suites that are affected by this, even if we propose a common way to setup proxy/dns for mangling the connections, the implementation details would change based on the context (e.g. while doing migration SUSE 12 to Leap there is no iptables available on Live CD environment and so on) and i'm sure test maintainers have more deep introspection depending on the circumstances (generally could be solved by just replacing zypper repositories urls, but won't cover all the cases).
Updated by RBrownSUSE almost 7 years ago
- Subject changed from [tools] tests must not have access to published repos, e.g. Tumbleweed -> mirror all on openQA instance? to [tools][functional] tests must not have access to published repos, e.g. Tumbleweed -> mirror all on openQA instance?
- Priority changed from High to Normal
- Target version deleted (
Milestone 8)
De-prioritising and retagging
After discussion in Tools group, the consensus is we'd would prefer to see this issue resolved in tests, not necessarily with additional tooling
Updated by okurz over 6 years ago
- Subject changed from [tools][functional] tests must not have access to published repos, e.g. Tumbleweed -> mirror all on openQA instance? to [tools][functional] tests must not have access to published repos, e.g. download.o.o on Tumbleweed -> remove all references to download.o.o from repos during installation and afterwards
- Description updated (diff)
- Status changed from Feedback to In Progress
- Priority changed from Normal to High
updated with acceptance criteria, tasks and effort estimation
Updated by okurz over 6 years ago
- Blocks action #12280: [opensuse][tw] Tumbleweed Test Suite gets packages from 'last published' oss repo added
Updated by okurz over 6 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: kde-sddm
https://openqa.opensuse.org/tests/520812
Updated by okurz over 6 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: clone_system
https://openqa.opensuse.org/tests/540854
Updated by okurz over 6 years ago
- Subject changed from [tools][functional] tests must not have access to published repos, e.g. download.o.o on Tumbleweed -> remove all references to download.o.o from repos during installation and afterwards to [tools][functional][medium] tests must not have access to published repos, e.g. download.o.o on Tumbleweed -> remove all references to download.o.o from repos during installation and afterwards
Updated by okurz over 6 years ago
- Has duplicate action #28438: [functional][opensuse] leap 15.0] package squid is missing added
Updated by okurz over 6 years ago
- Due date changed from 2017-12-05 to 2017-12-19
oops, should have gone to later sprint. Will discuss with PO.
Updated by okurz over 6 years ago
- Has duplicate action #28156: [opensuse][leap 15.0][functional] yast2-ncurses proxy server failed because of missing package squid added
Updated by okurz over 6 years ago
- feature switch. If yes, replace all download.o.o with corresponding content of MIRROR_HTTP
- validate that by running test locally which fails because of no access to any repo as o3 mirror gives 403 outside o3 network
- should still work if in MIRROR_HTTP the actual download.o.o is defined even though invalid testing snapshot version (what this ticket is about)
- allow access to all repos stored on o3 from everywhere so that anyone can clone jobs and reproduce locally or live with the drawback that local reproductions would always point to the wrong, outdated repos.
Updated by riafarov over 6 years ago
- Status changed from In Progress to Feedback
Copied text from the PR https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/4087:
For openSUSE it's hard to replace repos which we use. In most of the
scenarios it works fine as we don't install packages which are not
available on DVD or mirror in case of net install. Whereas it causes
issues in some scenarios when we install additional software in the
tests.
There are 2 parts for the solution, one is to modify repositories in the
installer, which is possible only by tweaking control.xml before we
trigger installation, or by at least disabling online repos which point
to download.opensuse.org. It's easier to handle scenario with installed
system and we already have test modules which do this task. As of now we
enable this behavior with feature variable and for test suites which
fail due to this particular issue. After we see that it works fine, we
can apply it as default behavior and exclude some scenarios if needed.
- Related ticket: poo#17436.
- Needles: PR#300.
- Verification runs:
- TW textmode missing MyODBC-unixODBC package in the mirror repo
- TW btrfs x11
- TW extra tests on gnome
- leap 15 create hdd gnome x11
- leap 15 text mode x11
Verification runs already have revealed that we may face issues with missing packages, so we should decide if we want to sync non-oss repo as well. As of now MyODBC-unixODBC is dropped. Code base wasn't updated in that run.
For AC2 we can only modify control.xml after using startshell boot option (a little easier with live installers). So I guess we should define scope where to apply solution first. Point about cloning jobs is still valid as would need manual adjustments if job is cloned.
After collecting feedback we can move forward in direction of what is required here.
zypper info tries to access source repo which is not available http://g226.suse.de/tests/129#step/zypper_info/6 , this was fixed by running zypper_info test before removing repos. In the scenario where we disable online repos during installation, this shouldn't harm.
After changes are merged, we can perform some runs with DISABLE_ONLINE_REPOS set to 1.
Updated by riafarov over 6 years ago
After changes are merged, we need to clone jobs with DISABLE_ONLINE_REPOS on o3 and see potential issues there and then apply it as default behavior.
Updated by lnussel over 6 years ago
There are tests that explicitly enable the online repos so the suggested solution looks like a workaround for a subset of tests to me
Updated by riafarov over 6 years ago
@lnussel yeah, I've identified that we are not sure what exactly is the subset, that's why we've created this variable. We can enable it for the test suites and identify those where it breaks something and then apply invert logic to make it a default behavior. Scope is just too big.
Here are some runs I've cloned with variable set:
https://openqa.opensuse.org/tests/565295#settings
https://openqa.opensuse.org/tests/565297#settings
https://openqa.opensuse.org/tests/565304#settings
https://openqa.opensuse.org/tests/565373#settings
I've enabled this setting on all create_hdd jobs, namely create_hdd_textmode create_hdd_gnome, create_hdd_kde, create_hdd_xfce
Updated by SLindoMansilla over 6 years ago
- Related to action #29366: [functional][easy][bsc#1073238] Add toolchain test for openSUSE added
Updated by okurz over 6 years ago
- Due date changed from 2017-12-19 to 2018-01-17
Updated by okurz over 6 years ago
- Target version changed from Milestone 12 to Milestone 13
Updated by okurz over 6 years ago
- Due date changed from 2018-01-17 to 2018-01-30
Updated by riafarov over 6 years ago
- Assignee changed from riafarov to okurz
Test runs look good as of now with disabled repos. @okurz, what should be our next steps then? Especially considering the fact that some tests require published repos (dup). And AC2 is not achievable in described way without hacking control.xml file.
Updated by riafarov over 6 years ago
- Due date changed from 2018-01-30 to 2018-02-13
- Target version changed from Milestone 13 to Milestone 14
@okurz will review progress and decide on next steps
Updated by okurz about 6 years ago
- Status changed from In Progress to Feedback
- Assignee changed from okurz to riafarov
sorry I missed to opportunity to discuss this more thoroughly before my vacation. I guess we should revisit this opportunity in about two weeks time.
Clearly we have not reached any of the two ACs and I understood that simply flipping the switch will break some tests.
So the online repos are disabled during installation in some test cases and we can see that live in e.g. https://openqa.opensuse.org/tests/605728#step/disable_online_repos/9
but the downstream job https://openqa.opensuse.org/tests/605816#step/zypper_lr/3 shows that the online repos are there in the installed system. So what did "disabling the online repos during installation" actually do? Only disable the use of these repos during installation? I think this is good and a step in the right direction. Now in this scenario if we would disable the online repos of course stuff would be missing trying to install e.g. yast modules but the job has the variable MIRROR_HTTP which was so far only used by debuginfo modules, see lib/kdump_utils.pm. So I assume we do not need to disable the online repos but rather replace them.
Could you try that - or argue against ;)
Updated by riafarov about 6 years ago
- Subject changed from [tools][functional][medium] tests must not have access to published repos, e.g. download.o.o on Tumbleweed -> remove all references to download.o.o from repos during installation and afterwards to [tools][functional][epic] tests must not have access to published repos, e.g. download.o.o on Tumbleweed -> remove all references to download.o.o from repos during installation and afterwards
Converting to the epic. I'll take a look why repos are not disabled. But as mentioned, for those kind of scenarios, we can enable another test module which does it and we already have it. For AC2 the only thing is to disable online repos, or to modify control file before we start installation (which we decided not to do). I'll create a task to enable switch where required and check if we have a bug in the installer to disable online repos.
Updated by okurz about 6 years ago
- Target version changed from Milestone 14 to Milestone 16
Ok, then a thing to review later. We can schedule the subtask before end of M16.
Updated by riafarov about 6 years ago
@okurz https://bugzilla.suse.com/show_bug.cgi?id=1081508 - so there is a bug and repos do not get disabled. The same is the case for leap. As per my comment above, we need to decide for other test suites to run test module which replaces repos:
sub replace_opensuse_repos_tests {
loadtest "update/zypper_clear_repos";
loadtest "console/zypper_ar";
}
It is the case already for some test suites, in particular for the test suite which was failing cause of problem we are trying to address here.
Updated by okurz about 6 years ago
- Has duplicate action #32332: [opensuse][functional][y][fast] repo bleed affecting gnuhealth installation added
Updated by okurz about 6 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: yast2_gui
https://openqa.opensuse.org/tests/632287
Updated by okurz about 6 years ago
- Due date changed from 2018-03-27 to 2018-04-24
due to changes in a related task
Updated by okurz about 6 years ago
- Has duplicate deleted (action #32332: [opensuse][functional][y][fast] repo bleed affecting gnuhealth installation)
Updated by okurz about 6 years ago
- Blocks action #32332: [opensuse][functional][y][fast] repo bleed affecting gnuhealth installation added
Updated by okurz about 6 years ago
- Blocks deleted (action #32332: [opensuse][functional][y][fast] repo bleed affecting gnuhealth installation)
Updated by okurz about 6 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: kde-sddm@64bit-2G
https://openqa.opensuse.org/tests/644378
Updated by okurz about 6 years ago
I created https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/4793 to explicitly enable update repos on TW and Leap after we merged riafarov's change to disable published repos - including the not-synced update-repo - by default. Let's see how far this brings us. I expect it's a bit dirty approach which will bite us eventually. But I also do not see a point in syncing the update repo because it's not linked to the builds in development.
Updated by okurz about 6 years ago
- Due date changed from 2018-04-24 to 2018-06-19
due to changes in a related task
Updated by okurz about 6 years ago
- Target version changed from Milestone 16 to Milestone 17
Updated by okurz about 6 years ago
I wonder about https://openqa.opensuse.org/tests/669973#step/installer_desktopselection/10 , isn't the installer test supposed to not enable or disable the online repos?
Updated by riafarov almost 6 years ago
- Due date changed from 2018-06-19 to 2018-04-24
due to changes in a related task
Updated by okurz almost 6 years ago
- Subject changed from [tools][functional][epic] tests must not have access to published repos, e.g. download.o.o on Tumbleweed -> remove all references to download.o.o from repos during installation and afterwards to [tools][functional][y][epic] tests must not have access to published repos, e.g. download.o.o on Tumbleweed -> remove all references to download.o.o from repos during installation and afterwards
Even though it's about "zypper_info" and such the subticket has been picked by the [y] team as well as this one so let's assign to [y] :)
Updated by riafarov almost 6 years ago
- Due date changed from 2018-04-24 to 2018-12-18
due to changes in a related task
Updated by okurz almost 6 years ago
- Target version changed from Milestone 17 to Milestone 17
Updated by okurz almost 6 years ago
- Target version changed from Milestone 17 to Milestone 22
Updated by okurz over 5 years ago
- Related to action #40286: [functional][y][opensuse] kdump_and_crash: the repo-name to refresh does not match added
Updated by mgriessmeier over 5 years ago
what's the right way to proceed here? ;)
Updated by riafarov over 5 years ago
I would say we cannot make next steps unless #34732 is resolved. We have strict space constraints for o3, and to completely get rid of published repos we have to reduce parts we sync. After that we need to apply new approach for testing updates.
Updated by okurz over 5 years ago
- Status changed from Feedback to Blocked
agreed, let's mark as "Blocked by subtask" then, ok?
Updated by riafarov over 5 years ago
- Due date changed from 2018-12-18 to 2019-01-15
due to changes in a related task
Updated by riafarov over 5 years ago
- Due date changed from 2019-01-15 to 2019-02-12
due to changes in a related task
Updated by riafarov over 5 years ago
- Due date changed from 2019-02-12 to 2019-02-26
due to changes in a related task
Updated by riafarov about 5 years ago
- Status changed from Blocked to Resolved
Finally we can resolve this one. I will create separate epic to be more efficient with assets, especially for SLE and sync only used and tested packages.
Updated by okurz about 5 years ago
- Related to action #42455: [opensuse][aarch64][functional][y] openSUSE Tumbleweed aarch64 oss repo seems to be deleted however we invest 41GB for the debuginfo repo added
Updated by szarate over 3 years ago
- Tracker changed from action to coordination
Updated by szarate over 3 years ago
See for the reason of tracker change: http://mailman.suse.de/mailman/private/qa-sle/2020-October/002722.html