Sync sles too on uyuni 2 #7640
Sync sles too on uyuni 2 #7640
Conversation
Bischoff
force-pushed
the
sync-sles-too-on-uyuni-2
branch
2 times, most recently
from
9dfb85d
to
ba0c61a
Compare
Bischoff
force-pushed
the
sync-sles-too-on-uyuni-2
branch
5 times, most recently
from
1f0ae13
to
c7ca9c4
Compare
| Then "orion-dummy-1.1-1.1.x86_64.rpm" package should have been stored | ||
| And solver file for "fake-rpm-suse-channel" should reference "orion-dummy-1.1-1.1.x86_64.rpm" | ||
|
|
||
| @uyuni |
There was a problem hiding this comment.
I would add the tag here (and the other scenarios related) to skip if the deployment of a build host VM is not present.
There was a problem hiding this comment.
I can't do it immediately because we don't have a @pxeboot tag (this channel is for the terminal, not for the build host)
| @scc_credentials | ||
| @uyuni | ||
| Scenario: Add SLES 15 SP4 product with recommended sub-products for the build host and the terminals | ||
| When I follow the left menu "Admin > Setup Wizard > Products" | ||
| And I wait until I do not see "Loading" text | ||
| And I enter "SUSE Linux Enterprise Server 15 SP4" as the filtered product description | ||
| And I wait until I see "SUSE Linux Enterprise Server 15 SP4 x86_64" text | ||
| And I open the sub-list of the product "SUSE Linux Enterprise Server 15 SP4 x86_64" | ||
| And I open the sub-list of the product "Basesystem Module 15 SP4 x86_64" | ||
| And I open the sub-list of the product "Desktop Applications Module 15 SP4 x86_64" | ||
| Then I should see that the "Basesystem Module 15 SP4 x86_64" product is "recommended" | ||
| And I should see that the "Server Applications Module 15 SP4 x86_64" product is "recommended" | ||
| When I select "SUSE Linux Enterprise Server 15 SP4 x86_64" as a product | ||
| Then I should see the "SUSE Linux Enterprise Server 15 SP4 x86_64" selected | ||
| And I should see the "Basesystem Module 15 SP4 x86_64" selected | ||
| And I should see the "Server Applications Module 15 SP4 x86_64" selected | ||
| When I select "Desktop Applications Module 15 SP4 x86_64" as a product | ||
| And I select "Development Tools Module 15 SP4 x86_64" as a product | ||
| Then I should see the "Desktop Applications Module 15 SP4 x86_64" selected | ||
| And I should see the "Development Tools Module 15 SP4 x86_64" selected | ||
| When I select "Containers Module 15 SP4 x86_64" as a product | ||
| Then I should see the "Containers Module 15 SP4 x86_64" selected | ||
| When I click the Add Product button | ||
| And I wait until I see "SUSE Linux Enterprise Server 15 SP4 x86_64" product has been added | ||
| Then the SLE15 SP4 product should be added |
There was a problem hiding this comment.
Can't we skip this synchronized then?
I understood by your discussion with Ondrej, that having on the build host VM our zypper repositories created coming from OBS development channels would be enough (having those injected through sumaform as we were doing till not many months ago). We will need ofc to enable/disable them when necessary.
That approach would be ideal for our long-term, as if we synchronize the full SLES15SP4 product in Uyuni CI just for this need, we will spending a precious time, and might not be adding real value if what we need here is the content and not that important the fact that this content comes from SCC repositories.
That would also fit better into the refactor I'm working on, otherwise, at very least, we need to include here a last step I developed in order to wait for SLES15SP4 product and all its sub-channels to be fully synced.
There was a problem hiding this comment.
You mean kill the synchronization ? Yes, that's the idea of a second PR after this one, as explained in the description.
Forget the problem of zypper repositories on build host, it's already solved. We cheat with a zypper install from local repos.
I also discovered that we already directly get the packages for the OS image from our mirror, so we're good there too if we don't reposync.
The problem is with Cobbler. There are two possible solutions at this time (not mutually exclusive):
- use Leap as test base for Cobbler (1)
- cheat in the autoyast file to get the packages directly from external repos or our mirror, like we do for Retail (2)
I'd like to first fix the Cobbler and Retail current problems, then try to shorten up the reposync with another PR.
(1) but then Leap must be fully synchronized (so I'm not sure we really win something...)
(2) but then we bypass completely the testing of autoyast variables like here:
<media_url>http://$redhat_management_server/ks/dist/child/sle-product-sles15-sp4-updates-x86_64/$distrotree</media_url>
and we don't test we have the correct packages on the suse manager server
There was a problem hiding this comment.
I like option 2, but I will give a though.
There was a problem hiding this comment.
It's even likely it's the only one that will work out.
I need to discuss with Dominik and/or you. Didn't we kill the reposync for sles? if we did, how could cobbler tests work? Maybe they didn't and we did never identify this as a source of instability?
Bischoff
force-pushed
the
sync-sles-too-on-uyuni-2
branch
5 times, most recently
from
36d0196
to
fb198ad
Compare
Co-authored-by: Oscar Barrios <obarrios@suse.com>
Bischoff
force-pushed
the
sync-sles-too-on-uyuni-2
branch
from
fb198ad
to
ca6f049
Compare
|
Tests passed, merging. |
What does this PR change?
First commit is about cleanup and nitpicks:
Second commit is a refactor done independantly by Oscar and me:
Third commit does the real stuff:
It should be followed by a new PR that kills SLES 15 SP4 reposync right after beginning and tests Cobbler on Leap.
Links
Ports:
Changelogs