search

uyuni-project / sumaform

Terraform configuration to quickly set up SUSE Manager/Uyuni environments
BSD 3-Clause "New" or "Revised" License
71 stars 71 forks source link

Is tools_additional_repo pointing to the right repos ? #722

Open Bischoff opened 4 years ago

Bischoff commented 4 years ago

In salt/repos/default.sls:

{% if 'nightly' in grains.get('product_version') | default('', true) %}
tools_additional_repo:
  pkgrepo.managed:
  - baseurl: http://{{ grains.get("mirror") | default("download.suse.de", true) }}/
       ibs/Devel:/Galaxy:/Manager:/4.0:/SLE15-SUSE-Manager-Tools/images/repo/
       SLE-15-Manager-Tools-POOL-x86_64-Media1/
  - priority: 98

(please note 4.0 in the URL)

but according to @juliogonzalez "it should be using Head" in 4.0 testsuite.

I have no idea why this would be wrong, to be clarified with Julio.

moio commented 4 years ago

I have no idea how we could end up with this situation but yes, of course, @juliogonzalez is right and we should use /ibs/Devel:/Galaxy:/Manager:/Head:/SLE15-SUSE-Manager-Tools/images/repo/SLE-15-Manager-Tools-POOL-x86_64-Media1/

Bischoff commented 4 years ago

OK, thanks @moio.

The situation is like this: all nightly point to 4.0, the rest points to Head.

SLE11SP4:

{% if 'nightly' in grains.get('product_version') | default('', true) %}
    - baseurl: http://{{ grains.get("mirror") | default("download.suse.de", true) }}/
       ibs/Devel:/Galaxy:/Manager:/4.0:/SLE11-SUSE-Manager-Tools/images/repo/
       SLE-11-SP4-CLIENT-TOOLS-ia64-ppc64-s390x-x86_64-Media1/suse/
{% elif 'head' in grains.get('product_version') | default('', true) %}
    - baseurl: http://{{ grains.get("mirror") | default("download.suse.de", true) }}/
       ibs/Devel:/Galaxy:/Manager:/Head:/SLE11-SUSE-Manager-Tools/images/repo/
       SLE-11-SP4-CLIENT-TOOLS-ia64-ppc64-s390x-x86_64-Media1/suse/

SLE12:

{% if 'nightly' in grains.get('product_version') | default('', true) %}
    - baseurl: http://{{ grains.get("mirror") | default("download.suse.de", true) }}/
       ibs/Devel:/Galaxy:/Manager:/4.0:/SLE12-SUSE-Manager-Tools/images/repo/
       SLE-12-Manager-Tools-POOL-x86_64-Media1/
{% elif 'head' in grains.get('product_version') | default('', true) %}
    - baseurl: http://{{ grains.get("mirror") | default("download.suse.de", true) }}/
      ibs/Devel:/Galaxy:/Manager:/Head:/SLE12-SUSE-Manager-Tools/images/repo/
      SLE-12-Manager-Tools-Beta-POOL-x86_64-Media1/

SLE15:

{% if 'nightly' in grains.get('product_version') | default('', true) %}
  - baseurl: http://{{ grains.get("mirror") | default("download.suse.de", true) }}/
     ibs/Devel:/Galaxy:/Manager:/4.0:/SLE15-SUSE-Manager-Tools/images/repo/
     SLE-15-Manager-Tools-POOL-x86_64-Media1/
{% elif 'head' in grains.get('product_version') | default('', true) %}
    - baseurl: http://{{ grains.get("mirror") | default("download.suse.de", true) }}/
      ibs/Devel:/Galaxy:/Manager:/Head:/SLE15-SUSE-Manager-Tools/images/repo/
      SLE-15-Manager-Tools-POOL-x86_64-Media1/

(if one of you have the time for an explanation why this is wrong, I would be grateful)

juliogonzalez commented 4 years ago

Let me do a short explanation:

Usually all versions except Head should use the client tools from the latest release. So on paper: 3.2 and 4.0 should use the client tools from 4.0. Soon this will change, we'll have 4.1 so 3.2, 4.0 and 4.1 will need to use the client tools from 4.1

Head should always use the client tools from head.

And May-June, when we are about to submit the "new" client tools from the codestream of the next major version of SUSE manager, all versions must use the Head client tools. That should be the situation right now. Reason: to test that the previous SUSE manager versions will work fine with the "new tools".

So as of today, having 4.0 there is wrong. 4.0 client tools are not maintained anymore. We need head.

Starting soon, having head will we wrong and we'll need to have 4.1 (exception: Head).

Hope it makes sense.

juliogonzalez commented 4 years ago

BTW: since this is something that needs to be changed "more or less frequently", I think we should manage this differently.

Let's avoid having the version hardcoded.

We should have some kind of variable such as client_tools_version with a default value for the version to be used for all environments except head. That can then be adjusted to 4.0, 4.1 or Head depending on what's needed in each moment. And then that value can be interpolated into the URLs at the salt/repos/ sls files

Bischoff commented 4 years ago

OK, now I understand: the customer always use the latest client tools. At the beginning of the cycle, the latest client tools are still on the previous version. But "at a certain point" the latest version will be on the version that is about to be published.

What determines the changing point? How can I know that you are "about to submit the new client tools from the codestream of the next major version" ? Is RC1 a good rule of the thumb?

srbarrios commented 3 years ago

This could be related to the current issue in our jobs?

https://ci.suse.de/view/Manager/view/Manager-Head/job/manager-Head-dev-acceptance-tests-NUE/2159/TestSuite_20Report/

Retrieving repository 'SLE-Manager-Tools15-BETA-Pool for x86_64 SP2' metadata [.error]
Repository 'SLE-Manager-Tools15-BETA-Pool for x86_64 SP2' is invalid.
[susemanager:sle-manager-tools15-beta-pool-x86_64-sp2|https://suma-head-pxy.mgr.suse.de:443/rhn/manager/download/sle-manager-tools15-beta-pool-x86_64-sp2?eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE2NjIwMzkyMDQsImlhdCI6MTYzMDUwMzIwNCwibmJmIjoxNjMwNTAzMDg0LCJqdGkiOiI0QWdWQlR1Ql84WXR4aFFYOXdTZmN3Iiwib3JnIjoxLCJvbmx5Q2hhbm5lbHMiOlsic2xlLW1hbmFnZXItdG9vbHMxNS1iZXRhLXBvb2wteDg2XzY0LXNwMiJdfQ.YIKVmDW8CEAnNaXnJ_H0B1S9ajPArXtK3YOSqTMuOXw] Valid metadata not found at specified URL
History:
 - [susemanager:sle-manager-tools15-beta-pool-x86_64-sp2|https://suma-head-pxy.mgr.suse.de:443/rhn/manager/download/sle-manager-tools15-beta-pool-x86_64-sp2?eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE2NjIwMzkyMDQsImlhdCI6MTYzMDUwMzIwNCwibmJmIjoxNjMwNTAzMDg0LCJqdGkiOiI0QWdWQlR1Ql84WXR4aFFYOXdTZmN3Iiwib3JnIjoxLCJvbmx5Q2hhbm5lbHMiOlsic2xlLW1hbmFnZXItdG9vbHMxNS1iZXRhLXBvb2wteDg2XzY0LXNwMiJdfQ.YIKVmDW8CEAnNaXnJ_H0B1S9ajPArXtK3YOSqTMuOXw] Repository type can't be determined.

Please check if the URIs defined for this repository are pointing to a valid repository.
Skipping repository 'SLE-Manager-Tools15-BETA-Pool for x86_64 SP2' because of the above error.
Retrieving repository 'SLE-Manager-Tools15-BETA-Updates for x86_64 SP2' metadata [.error]
Repository 'SLE-Manager-Tools15-BETA-Updates for x86_64 SP2' is invalid.
[susemanager:sle-manager-tools15-beta-updates-x86_64-sp2|https://suma-head-pxy.mgr.suse.de:443/rhn/manager/download/sle-manager-tools15-beta-updates-x86_64-sp2?eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE2NjIwMzkyMDQsImlhdCI6MTYzMDUwMzIwNCwibmJmIjoxNjMwNTAzMDg0LCJqdGkiOiJWZEFRUDNQbVQ1SzQ2dEZidEx0T05nIiwib3JnIjoxLCJvbmx5Q2hhbm5lbHMiOlsic2xlLW1hbmFnZXItdG9vbHMxNS1iZXRhLXVwZGF0ZXMteDg2XzY0LXNwMiJdfQ.S4u1occe6-fjVVP0RK3tQz9hIak9Iy9yRHfYLGqAIT4] Valid metadata not found at specified URL
History:
 - [susemanager:sle-manager-tools15-beta-updates-x86_64-sp2|https://suma-head-pxy.mgr.suse.de:443/rhn/manager/download/sle-manager-tools15-beta-updates-x86_64-sp2?eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE2NjIwMzkyMDQsImlhdCI6MTYzMDUwMzIwNCwibmJmIjoxNjMwNTAzMDg0LCJqdGkiOiJWZEFRUDNQbVQ1SzQ2dEZidEx0T05nIiwib3JnIjoxLCJvbmx5Q2hhbm5lbHMiOlsic2xlLW1hbmFnZXItdG9vbHMxNS1iZXRhLXVwZGF0ZXMteDg2XzY0LXNwMiJdfQ.S4u1occe6-fjVVP0RK3tQz9hIak9Iy9yRHfYLGqAIT4] Repository type can't be determined.

Please check if the URIs defined for this repository are pointing to a valid repository.
Skipping repository 'SLE-Manager-Tools15-BETA-Updates for x86_64 SP2' because of the above error.
juliogonzalez commented 3 years ago

I don't think so. In fact I wonder if this bug is not already fixed and should be closed.

What that error is telling you is that the Server doesn't have the Beta channels, probably beause they are not synced. Probably because Head does not see them for some reason (maybe @mcalmer can tell us again under what circumstances the beta channel tools are showing up)