openQA Project (public) » openQA Infrastructure (public)

most likely [epic] - to be discussed in sprint planning

no feedback from Ihno/Gerhard/Wolfgang until now

1 month ago you were explaining to mee that this is critical so do the other guys not share your concerns or what's going on? How high is the risk that SLE15 GMC validation will be impacted?

okurz wrote:

1 month ago you were explaining to mee that this is critical so do the other guys not share your concerns or what's going on? How high is the risk that SLE15 GMC validation will be impacted?

That's how it sounded to me...
I was asking 3 times in the last month but no one had any new information.
I'd be fine with just dropping this and if it pops up, add it as fast track

@mgriessmeier how would you see the current state, still "Workable"? Assigned to you or unassign?

just out of curiosity: is that done now? I know that we will get new HW in April for Live Patching as well.

nope, sorry, we still struggle to integrate it in the QA network.
but this is not related to Live patching HW

disabled hsi and ctc tests for Y-team and U-team:
https://gitlab.suse.de/qsf-y/qa-sle-functional-y/-/merge_requests/220
https://gitlab.suse.de/qsf-u/qa-sle-functional-userspace/-/merge_requests/95

replaced old with new workers (only 6 for now - more to come after testing)
https://gitlab.suse.de/openqa/salt-pillars-openqa/-/merge_requests/246/diffs

@mgriessmeier I think you removed all workers matching the still existing machine "s390x-zVM-hsi-l3" and a lot of tests scheduled against this machine are now piling up, e.g. see https://stats.openqa-monitor.qa.suse.de/d/7W06NBWGk/job-age?orgId=1&fullscreen&panelId=4&from=now-7d&to=now and the schedule on https://openqa.suse.de/tests/ . Can you suggest how to handle these scenarios? Should s390x-zVM-hsi-l3 still exist or is it obsolete? If the first, can you readd according classes, if the latter, please crosscheck with test maintainers what the equivalent worker classes would be. Also I suggest to remove machine classes that have no matching worker class behind.

okurz wrote:

@mgriessmeier I think you removed all workers matching the still existing machine "s390x-zVM-hsi-l3" and a lot of tests scheduled against this machine are now piling up, e.g. see https://stats.openqa-monitor.qa.suse.de/d/7W06NBWGk/job-age?orgId=1&fullscreen&panelId=4&from=now-7d&to=now and the schedule on https://openqa.suse.de/tests/ . Can you suggest how to handle these scenarios? Should s390x-zVM-hsi-l3 still exist or is it obsolete? If the first, can you readd according classes, if the latter, please crosscheck with test maintainers what the equivalent worker classes would be. Also I suggest to remove machine classes that have no matching worker class behind.

Hi Olli,

so hsi and ctc worker classes are deprecated now (as I also mentioned in my mail to the openqa mailinglist.

I disabled jobs with those worker classes for the Yast and the Functional group and was mentioning that those should be done for others as well.
But I will crosscheck still running scenarios and ensure to disable them.

Thanks, sound good. IMHO better this way that we crosscheck that no unintended test coverage drops :) We should re-enable the alert for "job schedule age" in https://stats.openqa-monitor.qa.suse.de/d/7W06NBWGk/job-age?orgId=1&panelId=5&fullscreen&edit&tab=alert after we have ensured that there are no more jobs scheduled against machines with worker classes that do not exist anymore and also that according machine definitions do not even exist anymore.

@mgriessmeier @osukup any progress? I currently do not see any stuck tests but machines like s390x-zVM-hsi-l3 still exist.

@mgriessmeier you are still the assignee for this ticket but I assume you do not actually plan any further steps for it. Could you assign to osukup and ask for the remaining steps to be done or will you do?

Trying to remove the machine definitions from OSD:

s390x-zVM-ctc   s390x   INSTALLONLY=1
S390_NETWORK_PARAMS=CTCProtocol=0 InstNetDev=ctc HostIP=10.161.189.@S390_HOST@ Hostname=s390ctc@S390_HOST@.suse.de Gateway=10.161.189.254 Nameserver=10.160.0.1 Domain=suse.de ReadChannel=0.0.0600 WriteChannel=0.0.0601 Pointtopoint=10.161.189.254
WORKER_CLASS=s390x-zVM-ctc

yields

Bad Request: Group SLE 12 SP5 YaST must be updated through the YAML template

and trying to remove

s390x-zVM-hsi-l2    s390x   INSTALLONLY=1
S390_NETWORK_PARAMS=OSAMedium=eth OSAInterface=qdio OSAHWAddr= InstNetDev=osa HostIP=10.161.183.@S390_HOST@/24 Hostname=s390hsl@S390_HOST@.suse.de Gateway=10.161.183.254 Nameserver=10.160.0.1 Domain=suse.de PortNo=0 Layer2=1 ReadChannel=0.0.7100 WriteChannel=0.0.7101 DataChannel=0.0.7102 Portname=trash
WORKAROUND_BUGS=bsc1156047
WORKER_CLASS=s390x-zVM-hsi-l2

s390x-zVM-hsi-l3    s390x   INSTALLONLY=1
S390_NETWORK_PARAMS=Portname=trash InstNetDev=osa OSAInterface=qdio OSAMedium=eth HostIP=10.161.185.@S390_HOST@/24 Hostname=s390hsi@S390_HOST@.suse.de Gateway=10.161.185.254 Nameserver=10.160.0.1 Domain=suse.de PortNo=0 Layer2=0 ReadChannel=0.0.7000 WriteChannel=0.0.7001 DataChannel=0.0.7002
WORKER_CLASS=s390x-zVM-hsi-l3

yields:

Bad Request: Group SLE 12 SP5 YaST must be updated through the YAML templateBad Request: Groups Maintenance: SLE 12 SP1 Incidents, SLE 12 SP5 YaST must be updated through the YAML template

Unfortunately there was no update from osukup (also no answer to chat messages).

EDIT: Managed to remove the ctc reference after deleting the last job template from https://openqa.suse.de/admin/job_templates/142 . The file says it is managed in git but actually the SLE12 files have been removed from https://gitlab.suse.de/qsf-y/qa-sle-functional-y in a commit which is just stating the obvious, not explaining why. I assume someone wanted to cleanup.

Also removed

    - qam-minimal:
        machine: s390x-zVM-hsi-l3
        settings:
          PATTERNS: 'minimal'

from https://openqa.suse.de/admin/job_templates/41 "Maintenance: SLE 12 SP1 Incidents" so I could delete both machines as well.