Project

General

Profile

action #12292

[test review] Missing assets in openQA

Added by sebchlad over 6 years ago. Updated over 6 years ago.

Status:
Resolved
Priority:
Immediate
Assignee:
Category:
-
Target version:
-
Start date:
2016-06-10
Due date:
% Done:

100%

Estimated time:
Difficulty:

Description

History

#1 Updated by coolo over 6 years ago

this is not an asset. this is a repo url its getting from the scc service. Not sure what we can do to fix that

#2 Updated by okurz over 6 years ago

also observed in sle-12-SP2-Server-DVD-HA-x86_64-Build0326@1602-ha+SCC@64bit https://openqa.suse.de/tests/442170#step/consoletest_setup/25

#3 Updated by okurz over 6 years ago

  • Assignee set to okurz

Looking at the logfiles from https://openqa.suse.de/tests/442170/file/install_and_reboot-y2logs.tar.bz2, especially zypp/history all repos are listed and I can see that the addon repo looks correct but all SLES repos are missing the build number as part of the path. Also, I checked all other log files including autoinst-log.txt and serial0.txt and vars.json and couldn't find any reference to a repo path there. As the repo path is a path on our openqa server, where is this generated? Is it "proxy-SCC"? Should we report this on bugzilla then?

#4 Updated by okurz over 6 years ago

  • Assignee changed from okurz to dzedro

dzedro please see questions in #12292#note-3, can you help?

#5 Updated by dzedro over 6 years ago

I guess problem is that BUILD is not number of Server|Desktop build number, but BUILD_HA@BUILD.

#6 Updated by okurz over 6 years ago

good point so it is a problem of SCC or more specifically Proxy-SCC? dzedro, can you point the right people to the current ticket?

#7 Updated by dzedro over 6 years ago

Could reproduce this

BUILD=0333@1614
http://10.100.51.190/tests/1968/modules/consoletest_setup/steps/19

BUILD=1614
http://10.100.51.190/tests/1964/modules/consoletest_setup/steps/21

I think BUILD should be build number of Server iso, not contain build number of Server and HA, it's confusing and is breaking things.
Or should SCC team change some regular expression to filter the correct build number ?

#8 Updated by coolo over 6 years ago

The HA release manager wants to see in the dashboard which version of the addon was tested - so we set BUILD to something bizzare

#9 Updated by dzedro over 6 years ago

This is answer from Artem Chernikov

Ok, I see. The @ symbol is not allowed in the URL as usually delimits
authorization piece. So, that URL is not safe to use and SCC-Proxy has a
hiccup over it. Generally we will not try to workaround the RFC to make
it possible, so we need to find a better way, say not to use that symbol
in the build. More importantly -
ftp://openqa.suse.de/SLE-12-SP2-SDK-POOL-s390x-Build0287-Media1/ does
not contain any build with such a name, so I wonder why
Server-0333@1614 is used and what is the purpose of the @ symbol.

#10 Updated by okurz over 6 years ago

so it's easy, dzedro invite Artem and RM to a discussion round OR work around that in openQA context

#11 Updated by coolo over 6 years ago

sorry, there is nothing wrong on scc side and it's not a workaround to fix openqa setup.

#12 Updated by coolo over 6 years ago

rsync.pl needs to have BUILD_SLES and BUILD_SLED (just as we have them for addons) and this needs to be used in SCC_URL instead of BUILD

#13 Updated by okurz over 6 years ago

"in openQA context" includes rsync.pl for me, I didn't mean to change the Web UI for that ;-)

#14 Updated by dzedro over 6 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#15 Updated by dzedro over 6 years ago

  • Status changed from Feedback to Resolved

#16 Updated by mgriessmeier over 6 years ago

  • Status changed from Resolved to In Progress

reopen for tracking
typo in variable, jozef is aware of that ;)
see e.g. https://openqa.suse.de/tests/446000#step/skip_registration/10

#17 Updated by dzedro over 6 years ago

  • Status changed from In Progress to Resolved

finally fixed

#18 Updated by okurz over 6 years ago

  • Status changed from Resolved to In Progress

please see bsc#987569. If the addon module is now necessary for aarch64 the pool channels need to be provided accordingly. I recommend to make sure the URLs gathered by (proxy-)SCC are always valid. The tests should be more explicit about what happens here.

#19 Updated by coolo over 6 years ago

  • Status changed from In Progress to Resolved

this is solved - and it wasn't really cool to reopen a completely unrelated issue for this.

Also available in: Atom PDF